Method and system for distributed processing management

ABSTRACT

A system for distributed process management comprising a plurality of units of software for installation on computing platform, and further software for controlling the operation of the plurality of units in use of the system,  
     wherein each unit of software is provided with means for communicating with other units of software, and at least some of the units of software are further provided with means for providing one or more elements of a software process,  
     said further software being capable of defining at least one set of software units and controlling communications by the units in the set to be limited to communication only with other units of the set.

[0001] The present invention relates to a method and system fordistributed processing management and finds particular application ininformation management.

[0002] It is known to use software agent systems (where an agentcomprises software code and usually at least local data which togetherprovide an entity which is to some extent autonomous and proactive) forthe manipulation and provision of information to users. These softwareagent systems are one means of implementing decentralised computationalprocesses.

[0003] There also exist software technologies for distributed computing,such as the Common Object Request Brokerage Architecture (CORBA) thatcan provide functionality for distributed computing similar to some ofthat provided by software agent systems.

[0004] In the construction of such software systems a contrast can bedrawn between centralised and decentralised approaches to the design andoperation of the software. Centralised approaches have the advantagethat the software may be better understood in advance of execution, andthat the flow of control is in principle clear. But they may also havethe disadvantage that the design is inflexible if the requirements oruse of the software changes between initial design and implementation.Hence there is an interest in more decentralised systems that start withsimple components and combine them to produce more complex systems.Decentralised approaches have the advantage that individual componentscan be well understood, and can be moved around if requirements for thesystem change. The disadvantage is that control in the system may beless predictable.

[0005] Because the development of particular software agent systems fromscratch for each application could lead to a lot of duplication ofsoftware, a number of software agent toolkits have been developed thatprovide the means of constructing a variety of different software agentsystems from one set of tools. While existing software agent toolkits,and other software technologies, do to some extent implementdecentralised computing systems, they do suffer from problems of:

[0006] Robustness [i.e. how to ensure that the system performs to therequired standard despite changes to its software environment that maybe disruptive to agent function.]

[0007] Scalability [i.e. how to ensure that what works with relativelyfew agents in a test application works as well with many agents in areal-world application.]

[0008] Robustness and scalability have been addressed in a number ofways in existing software agent systems, with varying degrees ofsuccess. These are important issues to address if such softwaretechnologies are to provide solutions to industrially or commerciallysignificant application problems.

[0009] According to the present invention, there is provided a method orsystem as set out in the accompanying claims. Further inventive aspectsof the invention are described below and set out in the drawings.

[0010] A software system referred to herein as the “DIET” system willnow be described as an embodiment of the present invention, by way ofexample only, with reference to the accompanying drawings in which:

[0011]FIG. 1 shows a block diagram of components of the DIET system, inparticular the relationship between software agents (usually referred toas “Infohabitants” in the following description) and an environment inwhich they are located, showing use of proxies;

[0012]FIG. 2 shows schematically the use of threads, available by meansof an operating system of computing platform supporting the system, andtheir allocation to Infohabitants by the environment of FIG. 1;

[0013]FIG. 3 shows a basic structure of an Infohabitant, in particularin relation to the response of the software agent to external events;

[0014]FIG. 4 shows in flow diagram a process by means of which a newInfohabitant is created;

[0015]FIG. 5 shows in flow diagram a process for handling Infohabitantmigration. FIG. 5a) shows the process at the source environment and FIG.5b) shows the process at the destination environment;

[0016]FIG. 6 shows in flow diagram a process for handling incomingmessages for Infohabitants;

[0017]FIG. 7 shows in flow diagram a process for handling incomingconnection notifications for Infohabitants;

[0018]FIG. 8 shows in flow diagram a process for implementing messagedelivery;

[0019]FIG. 9 shows in flow diagram a process for setting up newconnections between Infohabitants;

[0020]FIG. 10 shows in flow diagram an alternative process for settingup new connections between Infohabitants;

[0021]FIG. 11 shows in flow diagram an execution flow for a process tobe carried out by an Infohabitant;

[0022]FIG. 12 shows in flow diagram a process for handling a request forsetting up a new connection;

[0023]FIG. 13 shows in flow diagram a process for handling a request tosend a message.

[0024]FIG. 13(a) shows the process at the source end of the connectionand FIG. 13 (b) shows the process at the receiving end of theconnection;

[0025]FIG. 14 shows, in flow diagram, functionality of an Infohabitant.FIG. 14(a) shows its functionality in handling new connections and FIG.14(b) shows its functionality in handling incoming messages;

[0026]FIG. 15 shows schematically an example configuration of a basicInfohabitant in connecting three client Infohabitants to two serverInfohabitants;

[0027]FIG. 16 shows a flow diagram of steps in setting up a DIET systemon a computer;

[0028]FIG. 17 shows a screen shot of an application running on the DIETsystem;

[0029]FIG. 18 shows schematically a general architecture for a DIETsystem.

THE DIET SOFTWARE PLATFORM

[0030] In the following, reference is made to “Decentralised InformationEcosystem Technologies” (DIET) and to the DIET platform. These arereferences to embodiments of the present invention.

[0031] The DIET platform is primarily software which can be installed onone or more computers and used in running distributed applications. Itprovides software agents which can run processes involved in supportingan application, and in which the user can instaii processes which arcthe application. The platform also provides support to the softwareagents in their interactions with the computers on which they areinstalled, such as using the computer operating system (OS) to accessand coordinate processing capacity, for instance by thread allocation,and to store or display results. It also provides support to thesoftware agents in their creation, migration and expiry, and inter-agentcommunications.

[0032] In such a platform, many aspects are variable. The DIET softwareplatform is designed to form the base for information managementapplications. To be useful in practice, the platform needs to supportapplications that are:

[0033] adaptive: Information gets updated constantly, and newinformation is generated. Users of the information, and theirpreferences, as well as the system load and infrastructure, can alsochange. To operate efficiently, information management applications haveto adapt to these changes.

[0034] scalable: There is a massive amount of information available inthe real world, consider for example the World Wide Web. For aninformation management system to be useful, it needs to be built withoutany implicit limits on its size.

[0035] robust: Failures are inevitable in large-scale, dynamic,distributed systems. So the system needs to be able to cope with them.It needs to handle failing hardware, as well as cope with high systemload. Performance should gracefully deteriorate when parts of the systemfail.

[0036] decentralised: A lot of information is located in a distributedform, as the World Wide Web demonstrates. Decentralisation also helps toenhance scalability, by avoiding critical bottlenecks, and robustness,as it reduces the reliance on particular parts of the system.

[0037] The DIET platform has therefore been designed with theseproperties in mind.

[0038] The DIET platform has been developed initially with comparativelylightweight agents. If individual agents can be kept as lightweight aspossible, many more agents can be incorporated in the system, and theirnumbers can be varied much more easily. While the development oflightweight agents precludes the inclusion of some computationallyintensive capabilities at the individual agent level, there is potentialfor the emergence of such properties in the overall system, throughinteractions between agents. This emphasis on lightweight agents andbottom-up interaction does not however preclude the incorporation ofmore heavyweight agents where required when extending this platform.More heavyweight agents may, for example, be needed to includesophisticated reasoning or communication capabilities. Nor does itpreclude the use of more top-down Artificial Intelligence techniques,which complement and enhance the functionality provided by bottom-upinteractions.

[0039] The lightweight, bottom-up design should also contribute to theaim of supporting adaptive responses in the platform. Lightweight agentscould more easily serve as the subject of population-based adaptive,evolutionary, algorithms. In addition, the diversity of possibleconfigurations possible in interactions between lightweight agentsshould assist the search for robust solutions, and allow easymodification if these are not initially found.

[0040] The flexibility of the design approach of the DIET softwareplatform makes it suitable to support for instance a variety ofdifferent information manipulation applications, based upon a set ofinformation processing operations that will be required by some or allapplications. At the same time it can provide a platform for the studyof research issues concerning interactions in multi-agent systems.

[0041] Advantages of embodiments of the present invention are:

[0042] A way of regulating interaction between agents and theirsupporting environment, ensuring that all interaction is indirect byusing a specific system of proxies

[0043] The ability to associate a context with each communicationbetween agents, allowing agents to be lightweight and interactions toexecute efficiently

[0044] The rejection of messages, connections or migration as amechanism for controlling the overall activity and memory use of thesystem

[0045] A naming scheme for agents based on Bitstrings, allowing accessto individual agents by way of their identity or by using a particularfamily they belong to

[0046] The use of an event portal by each agent to handle all incomingevents efficiently

[0047] The ability to target specifically where to add capability forobserving events

[0048] The indirection of service requests through individual agents

[0049] The provision for reusable threads and the sharing of threads

[0050] The provision for resource accounting

[0051] Implementation

[0052] The DIET platform is a software system written in the Javaprogramming language. Because Java is an object-oriented programminglanguage, all components of the system mentioned here are objects in theobject-oriented programming sense. It will run on any computer which hasa suitable Java Virtual Machine installed. Interaction with the systemby a user or users will take place via a graphical user interfaceimplemented on the user's computer through its monitor and input devicessuch as mouse and keyboard.

[0053] (It will be understood that a “Class” is a basic concept inobject-oriented programming. A class is an object-oriented module thatdescribes the implementation of a “type” of object, including thecategories of data associated with objects of that type. Every object isan instance of a specific class. Different objects of the same classdiffer in their data content.)

[0054] Layered Architecture

[0055] Referring to FIG. 18, the DIET platform architecture has threelayers, a core layer 1800, an Application Reusable Component (ARC) layer1805 and the application layer 1810.

[0056] The core layer 1800 provides the fundamental functionalityavailable to all implementations in the DIET architecture and theconstraints under which all DIET agents must operate. It does thisprimarily by providing the “DIET Kernel” which is a set of Java classes.For instance, in an embodiment of a DIET platform for running anapplication, the DIET kernel will be used to provide objects of theclasses: World; Environment; ThreadPool; Listeners; and Infohabitants.

[0057] DIET agents are in fact all objects of the Infohabitant class,reflecting the particular suitability of DIET implementations toinformation management, and this terminology is generally used below.

[0058] The agents themselves (i.e. Infohabitants) are in the ARC andapplication layers 1805, 1810. The ARC layer 1805 includes optionalcomponents that are useful to various applications. These may beInfohabitants or Listeners. An example of an Infohabitant is theCarrierPigeon agent for communicating between different environmentswhich is further described below. Listeners are objects that allow forthe validation and testing of DIET applications, and for visualisationof the components within the platform. Listeners are a known class inJava but the DIET platform extends the class. An example of generalvisualisation and testing components the ARC layer 1805 might provideare EventDumperListeners. Each InfohabitantGuardian and ConnectionEndproxy maintains a respective list of listener objects, i.e.EventDumperListeners, that are interested in receiving a briefdescription of every event that occurs (e.g. every Infohabitant thatmigrates, each message that is sent, every connection that is set up).When such an event occurs, the InfohabitantGuardian, or ConnectionEndproxy, sends a corresponding brief description of that event to thoselisteners. The EventDumperListeners can display (on the computermonitor) the brief descriptions received from the InfohabitantGuardiansand ConnectionEnd proxies.

[0059] The application layer 1810 contains application-specific code.This will be loaded as processes in Infohabitants. Associated with theapplication layer 1810 may also be application-specific validationcomponents, to enable validation of the applications developed using theDIET platform.

[0060] The three layers of DIET systems are now each described in moredetail.

[0061] Core Layer 1800

[0062] As mentioned above, the core layer 1800 provides the DIET kernel.The functionality the DIET kernel provides can be used, but notmodified, by higher layers, particularly by Infohabitants in the ARC andapplication layers 1810. The following takes each of the main classesprovided by the DIET kernel and discusses it in detail.

[0063] Worlds

[0064] “Worlds” and “environments” are known concepts in multi-agentsystems, implemented for instance in Java developments. The DIETplatform implements one World per Java Virtual Machine. Within this allother elements of the system exist. There can be multiple Worldssimultaneously as multiple Java Virtual Machines are implemented. Thiswill happen if DIET runs on several computers. Within each World, theDIET platform implements one or more Environments. An environment alwaysresides on a single computer. However, one computer can host multipleenvironments.

[0065] To set up a DIET application, there has to be access to a World.Also, debugging and visualisation tools require access to the World.However, for security, Infohabitants should not have access to theWorld. A simple mechanism is used to provide the appropriate access tothe World. The World implementation in Java allows any Object to get areference to the World as long as it does not yet contain anyEnvironments. Once it contains one or more Environments, this mechanismis disabled (however, any Object that already obtained a reference tothe World can still use it). In practice this means that after thesimulation has been created, access to the World is only available to“trusted” Objects that were created before the simulation was set up.

[0066] The world creates the ListenerCookie that Listeners need toobserve InfohabitantGuardians and ConnectionEnds. Whenever a newEnvironment is added, the world provides it with a reference to theListenerCookie. The Environment in its turn, gives the reference also toevery InfohabitantGuardian it creates. Lastly, the InfohabitantGuardianprovides it to every ConnectionEnd it creates. In this way, theListenerCookie is known to all kernel objects that need to use it. TheWorld is the only kernel object that provides external access to thecookie. In this way, debugging tools can use it to listen to events (andvisualise them when that is desired).

[0067] It should be noted that the use of cookies for controlling accessis known. The following publication is an example: Czajkowski, G. & vonEicken, T. 1998 Jres: a resource accounting interface for Java. In:Proc. 1998 ACM OOPSLA Conference, Vancouver, October 1998.

[0068] The following comprises documentation about the World class.

[0069] org.ist_uie.diet.core.imp

[0070] Class World

[0071] java.lang.Object

[0072] |

[0073] +-org.ist_uie.diet.core.imp.World

[0074] public class World

[0075] extends java.lang.Object Constructor Summary protected World( )Method Summary void addWorldListener(WorldListener I) Register a worldlistener. It receives events whenever an environment is added or removedfrom the world. protected void fireEnvironmentAdded(BasicEnvironmentenv) Notify interested listeners that an environment is added to theworld. protected void fireEnvironmentRemoved(BasicEnvironment env)Notify interested listeners that an environment is removed to the world.BasicEnvironment get(EnvironmentAddress address) Retrieves anenvironment given its name. java.lang.Object getCookie( ) Returns thecookie for this world. Owners of this cookie have access to methods thatprovide “god like” powers over the world. The cookie for instance allowsdebugging and visualisation tools to listen to connections for specificevents. static World getEmptyInstance( ) Returns a Singleton instance ofthe world. boolean register(BasicEnvironment env) Registers the givenenvironment. It is stored such that it can easily be retrieved by itsaddress. void removeWorldListener(WorldListener I) Unregisters a worldlistener. void unregister(BasicEnvironment env) Unregisters the givenenvironment.

[0076] Environments

[0077] Each Infohabitant has a reference to its InfohabitantGuardian,which in turn has a reference to its Environment. These references areinitialised by the kernel each time that an Infohabitant enters anenvironment, i.e. upon creation of the Infohabitant and after migrationof the Infohabitant from one Environment, usually its initialEnvironment, to another Environment. An Infohabitant's currentEnvironment will provide access to the basic services provided by theDIET kernel. Infohabitants can only communicate directly when they areconnected and they can only set up direct connections to Infohabitantsin the same Environment.

[0078] The DIET Environment class is an interface—i.e. a Java constructwhose properties can be inherited by multiple classes, and which cannotitself be used to instantiate an object. The BasicEnvironment classprovides the functionality needed to create a DIET Environment object.Two types of Basic Environment can be created: both have a name (aString) and a DIET World associated with them; the second also has anassociated ThreadPool and a parameter which regulates the number ofconnections possible in that environment. A number of operations (Javamethods) can be carried out in BasicEnvironment:

[0079] EnvironmentListeners can be added to the Environment.

[0080] NeighbourhoodListeners can be added to the Environment.

[0081] The [Basic]Environment can be added to a Neighbourhood.

[0082] An Infohabitant can be created.

[0083] The execution of all Infohabitants in the Environment can befrozen.

[0084] The execution of all Infohabitants in the Environment can beunfrozen.

[0085] Interested Listeners can be informed that an Infohabitant hasarrived in the Environment.

[0086] Interested Listeners can be informed that an Infohabitant hasbeen created in the Environment.

[0087] Interested Listeners can be informed that an Infohabitant hasdeparted from the Environment.

[0088] Interested Listeners can be informed that an Infohabitant hasbeen destroyed in the Environment.

[0089] Interested Listeners can be informed that a Neighbourhood hasbeen added.

[0090] Interested Listeners can be informed that a Neighbourhood hasbeen removed.

[0091] The address of the Environment can be obtained.

[0092] EnvironmentListeners can be removed.

[0093] NeighbourhoodListeners can be removed.

[0094] The following comprises documentation about the DIET Environmentclass.

[0095] org.ist_uie.diet.core.imp

[0096] Class BasicEnvironment

[0097] java.lang.Object

[0098] |

[0099] +-org.ist_uie.diet.core.imp.BasicEnvironment

[0100] public class BasicEnvironment

[0101] extends java.lang.Object

[0102] A basic implementation of a DIET (core layer 1800) environment.Constructor Summary BasicEnvironment(java.lang.String name, World world)Constructor. BasicEnvironment(java.lang.String name, World world,ThreadPool thread_pool, int max_owned_connections) Constructor.

[0103] Method Summary void addEnvironmentListener(EnvironmentListener I)Register an environment listener. voidaddNeighbourhoodListener(NeighbourhoodListener I) Register aneighbourhood listener. void addToNeighbourhood(EnvironmentAddressaddress) Register to neighbourhood. Infohabitant create(InfohabitantImpprototype, java.lang.Object params) Identity Create an Infohabitant.void defrost( ) Resumes the execution of all Infohabitants. protectedFireInfohabitantArrived(InfohabitantGuardian infohab, voidEnvironmentAddress origin) Inform interested listeners that anInfohabitant is arrived. protectedFireInfohabitantCreated(InfohabitantGuardian infohab) void Informinterested listeners that an Infohabitant is created. protectedfireInfohabitantDeparted(InfohabitantGuardian infohab, voidEnvironmentAddress destination) Inform interested listeners that anInfohabitant is departed. protectedfireInfohabitantDestroyed(InfohabitantGuardian infohab) void Informinterested listeners that an Infohabitant is destroyed. protectedfireNeighbourAdded(EnvironmentAddress address) void Inform interestedlisteners that a neighbour is added. protectedfireNeighbourRemoved(EnvironmentAddress address) void Inform interestedlisteners that a neighbourhood is removed. Environment getAddress( )Address Get address of the environment. voidremoveEnvironmentListener(EnvironmentListener I) Unregisters anenvironment listener. boolean removeFromNeighbourhood(EnvironmentAddressaddress) Unregisters an environment neighbourhood. voidRemoveNeighbourhoodListener(NeighbourhoodListener I) Unregisters aneighbourhood listener. void startFreeze( ) Requests that allInfohabitants temporarily suspend their execution.

[0104] Thread Pool

[0105] Referring to FIG. 2, a ThreadPool 200 represents a novelarrangement in DIET systems which allows particularly efficient andflexible use of the processing capacity available to a DIET application.In order to run its code, a software agent must be allocated a thread205 by the operating system of the computer it is installed on. TheThreadPool object maintains a set of threads 205 which Infohabitants 210can access when they need to run a process. An Infohabitant canrelinquish its thread. 205 and become dormant and the thread becomesavailable to be picked up by another Infohabitant 215. This arrangementcontrols the maximum demand the DIET application can make on processingcapacity and also reduces the load represented by thread managementitself, for instance because threads are no longer created and discarded(also known as destroyed).

[0106] The Environment is responsible for allocating Threads toInfohabitants. A Thread is an Operating-System concept and can bedefined as a context sequentially executing instructions. On creation,Environments provide every Infohabitant with their own Thread. The DIETplatform does not prevent Infohabitants from creating and usingadditional Threads, but it can be advantageous to strictly limit everyInfohabitant to use one Thread at most.

[0107] Infohabitants can temporarily give up their Thread. When anInfohabitant has nothing to do, it can give up its thread. Infohabitantswithout a Thread are Dormant 210. When an event occurs the DIET kernelwill attempt to give the Infohabitant a thread to handle the event. FIG.6 for instance shows what happens when a message is sent to anInfohabitant. Similar block diagrams can be shown when a connection iscreated or destroyed. This technical implementation detail means thatthe number of Threads required by the platform can be relatively low. Asa result, you can run simulations on a single computer withsignificantly more Infohabitants than would otherwise be possible.MADKit is another multi-agent system that does not require a Thread foreach Agent. However, their implementation is significantly different anddeviates from the autonomy normally associated with agents in agentsystems.

[0108] Every Environment has access to a ThreadPool 200. A ThreadPoollimits the number of threads allocated by it that are in use at anymoment. It will not provide another thread as long as the limit isreached. An Environment can have its own ThreadPool, but it can also beshared by multiple Environments 100. In the latter case you can limitthe total number of Threads used by a group of Environments withoutfixing the allocation of Threads to each Environment.

[0109] When Threads are discarded, the ThreadPool is automaticallynotified. The Thread can then be put back into the pool, which avoidsthe overhead associated with creating and destroying Threads. (This wayof reusing threads is, however, not unique, and has for instance beenapplied in the Voyager ORB.)

[0110] The ThreadPool class is used to instantiate ThreadPool objects.There has to be a preexisting thread—otherwise ThreadPool could not beexecuted—but the ThreadPool provides a means of providing a convenientpool of threads for access by processes running in DIET. Whether thethreads in the ThreadPool are directly inherited from the preexistingthread can vary with the OS.

[0111] Three variants of ThreadPool can be constructed:

[0112] 1. a ThreadPool that limits the number of threads that can be inuse at one time. A default size of 200 is used for the pool size (thetotal number of possible threads, in use or not).

[0113] 2. a ThreadPool that limits both the number of threads in use andthe number in the pool. A default value of “null” is given for thethread group—a grouping of threads of equal priority—which means thatthe new ThreadPool inherits the thread group from the Thread on which itis constructed.

[0114] 3. a ThreadPool that limits both the number of threads in use andthe number in the pool, and provides a value for the thread group.

[0115] The ThreadPool provides a pool of threads.

[0116] Once a ThreadPool has been constructed the getExecutor method canbe used to run a task on a separate thread within it. Once the task iscompleted, the thread returns to the pool. The only occasion thegetExecutor method will fail to work is when all the threads are in useat once—then it will exit and return the value “null”. Another method,notifyTaskDone is used to signal that the thread has completed the task.

[0117] Thread group parameter: the thread group parameter actuallyidentifies a particular thread group (it is of type ThreadGroup)—so itcan be used to assign the attributes of that (existing) thread group tothe thread pool that is being created by ThreadPool. This allowsattributes such as priority to be set among the set of threads in theThreadPool.

[0118] Thread group versus pool versus threads in use: a thread group is(from Java API specification athttp://java.sun.com/products/jdk/1.2/docs/api/index.html) a set ofthreads defined by the ThreadGroup class (part of the Java API). Itprovides a means of dealing with groups of threads. A thread pool is anobject instantiated in DIET by the ThreadPool class (part of the DIETAPI) which is used to hold multiple threads these threads may or may notall belong to the same thread group. The thread pool class provides theadditional advantages, compared to the thread group, of being able todefine the maximum number of threads, and maximum number of activethreads in the pool, and having threads revert to the pool for reuseafter becoming inactive.

[0119] The interesting feature of the ThreadPool is not how it gets holdof threads but what it does with them. This is controlled by theThreadPool class in the DIET kernel.

[0120] Interesting aspects:

[0121] 1) A way of constraining the overall number of ‘parallel’ threadswhich execute on a machine.

[0122] a) Execution: Whether the underlying machine is serial orparallel, this helps to minimise the overhead associated with schedulingand synchronising threads. When the number of threads is very large, anoverriding proportion of the computational power of the machine can bedevoted simply to managing threads, rather than actually doing anything.

[0123] b) Memory Overhead: Threads of execution generally requireassociated memory to maintain the state of the executing code, as wellas storage for the state of the thread, (as managed by the OS).

[0124] c) Creation overhead: Threads of execution must be constructed.This implies a startup cost. Using a thread pool allows Threads to bere-used, eliminating this startup cost once all threads are created.Threads are recovered after their execution completes, and can thentarget a new piece of code.

[0125] 2) Exploitation of Thread Pools within the DIET core—responsiveagents. DIET aims to exploit the dynamics arising from very largenumbers of agents interacting. When there is an upper limit (imposed bythe OS, or by system resource constraints) on the number of Threadswhich can run at a given time, the DIET platform supports many more‘live’ agents than the number of available threads. Agents can enter a‘reactive’ phase, within which they are awaiting input from outside, andwill remain totally inert otherwise. Nevertheless, they still maintainstate, and can be targeted by means of their identity, i.e. that theiridentity is used in a destination sense when another agent wishes toinitiate communication with them. Events, such as the initiation of aconnection, take place through the DIET core, which may allocate aThread from the thread pool to allow the agent to respond to the event.

[0126] The following comprises documentation about the ThreadPool class.

[0127] org.ist_uie.diet.core.imp

[0128] Class ThreadPool

[0129] java.lang.Object

[0130] |

[0131] +-org.ist_uie.diet.core.imp.ThreadPool

[0132] public class ThreadPool

[0133] extends java.lang.Object

[0134] Maintains a pool of reusable threads. Threads can be used toexecute Runnable tasks. After it has finished, the thread does notterminate, but it is ready to execute another task. In this way, a newthread does not have to be created each time something needs to beexecuted in a separate thread. Constructor Summary ThreadPool(intmax_num_threads) Constructor. It uses a default value of 200 for themaximum pool size. Parameters: max_num_threads - the maximum number ofthreads that can be in use at any moment. ThreadPool(intmax_num_threads, int max_pool_size) Constructor. It uses a default valueof “null” for the thread group. Parameters: max_num_threads - themaximum number of threads that can be in use at any moment.max_pool_size - the maximum number of unused threads to maintain.ThreadPool(int  max_num_threads,  int  max_pool_size,java.lang.ThreadGroup thread_group) Constructor. Parameters:max_num_threads - the maximum number of threads that can be in use atany moment. max_pool_size - the maximum number of unused threads tomaintain. thread_group - the thread group for all threads. When it is“null”, a default thread group is created (where the priority of eachthread is Thread.NORM_PRIORITY). Method Summary org.ist_uie.GetExecutor( ) diet.core. Executes the given task in a separate thread.imp.ThreadPool. The method has been designed such that it Executor doesnot block and returns as quickly as possible. If the task cannot beexecuted because there are no available threads, the method exitsimmediately and returns “false”. protected voidnotifyTaskDone(org.ist_uie.diet. core.imp.ThreadPool.Executor executor)free a thread

[0135] Listeners

[0136] Listeners are the means by which monitoring and visualisation ofthe DIET system can be carried out. By having Listeners as objects whichare notified of all events affecting certain Infohabitants, or of allevents of selected types for instance, the data accumulated by aListener can be processed for various purposes.

[0137] The following comprises documentation about the Listener classesin DIET.

[0138] There are six listeners in the embodiment of the invention beingdescribed: ConnectionEndListener, EnvironmentListener,InfohabitantListener, NeighbourhoodListener, RunListener, andWorldListener, all of which extend java EventListener.

[0139] org.ist_uie.diet.core.imp.event

[0140] Interface ConnectionEndListener

[0141] All Known Implementing Classes:

[0142] ConnectionEndEventTracker

[0143] public abstract interface ConnectionEndListener

[0144] extends java.util.EventListener

[0145] Listens to connections for messages being sent and received.Method Summary void messageAccepted(ConnectionEndEvent e) Called when amessage was sent, and has been accepted on the other end. voidmessageReceived(ConnectionEndEvent e) Called when an Infohabitant hasreceived a message. void messageRejected(ConnectionEndEvent e) Calledwhen a message was sent, but it was rejected by the receivingInfohabitant. void messageSent(ConnectionEndEvent e) Called when anInfohabitant has sent a message.

[0146] org.ist uie.diet.core.imp.event

[0147] Interface EnvironmentListener

[0148] All Known Implementing Classes:

[0149] EnvironmentEventTracker

[0150] public abstract interface EnvironmentListener

[0151] extends java.util.EventListener

[0152] Listens to environments for births, deaths and movements ofInfohabitants. Method Summary void InfohabitantArrived(EnvironmentEvente) Called when an Infohabitant is arrived. voidInfohabitantCreated(EnvironmentEvent e) Called when an Infohabitant iscreated. void InfohabitantDeparted(EnvironmentEvent e) Called when anInfohabitant is departed. void lnfohabitantDestroyed(EnvironmentEvent e)Called when an Infohabitant is destroyed.

[0153] org.ist_uie.diet.core. imp.event

[0154] Interface InfohabitantListener

[0155] All Known Implementing Classes:

[0156] InfohabitantEventTracker

[0157] public abstract interface InfohabitantListener

[0158] extends java.util.EventListener

[0159] Listens to Infohabitants for connections being setup anddestroyed. Method Summary void connectionCreated(InfohabitantEvent e)Called when a connection is created. voidconnectionDestroyed(InfohabitantEvent e) Called when a connection isdestroyed. void connectionRejected(InfohabitantEvent e) Called when aconnection is rejected by an Infohabitant.

[0160] org.ist_uie.diet.core.imp.event

[0161] Interface NeighbourhoodListener

[0162] All Known Implementing Classes:

[0163] NeighbourhoodEventTracker, NeighbourhoodEventDumper

[0164] public abstract interface NeighbourhoodListener

[0165] extends java.util.EventListener

[0166] Listens to environments for environments being added and removedto/from their neighbourhood. Method Summary voidneighbourAdded(NeighbourhoodEvent e) Called when an environmentneighbourhood is added. void neighbourRemoved(NeighbourhoodEvent e)Called when an environment neighbourhood is removed.

[0167] org.ist_uie.diet.core.imp.event

[0168] Interface RunListener

[0169] public abstract interface RunListener

[0170] extends java.util.EventListener

[0171] Listens to Infohabitants for events concerning its execution. Asshown below, it listens for “runTerminated” but it could alternativelyor additionally include other events (for instance “runPaused” and“runResumed”). Method Summary void runTerminated(RunEvent e) Called whena running is terminated.

[0172] org.ist_uie.diet.core.imp.event

[0173] Interface WorldListener

[0174] All Known Implementing Classes:

[0175] WorldEventTracker, WorldEventDumper

[0176] public abstract interface WorldListener

[0177] extends java.util.EventListener

[0178] Listens to worlds for environments being added and removed.Method Summary void environmentAdded(WorldEvent e) Called when anenvironment is added. void environmentRemoved(WorldEvent e) Called whenan environment is removed.

[0179] The following comprises documentation about Event classesexternal to DIET which Listener classes are provided to respond to.

[0180] There are six events in the embodiment of the invention beingdescribed: ConnectionEndEvent, EnvironmentEvent, InfohabitantEvent,NeighbourhoodEvent, RunEvent, and WorldEvent, all of which extend javaEvent.

[0181] These events are external to DIET, and they are mainly used foranalysis and visualisation.

[0182] org.ist uie.diet.core.imp.event

[0183] Class ConnectionEndEvent

[0184] java.lang.Object

[0185] |

[0186] +-java.util.EventObject

[0187] |

[0188] +-org.ist_uie.diet.core.imp.event.ConnectionEndEvent

[0189] public class ConnectionEndEvent

[0190] extends java.util.EventObject

[0191] Basic event object for “connection end” events.

[0192] See Also:

[0193] ConnectionEndListener, Serialized Form Constructor SummaryConnectionEndEvent(ConnectionEnd connection, InfohabitantGuardiansender, InfohabitantGuardian receiver, CommunicationPacket packet) Anevent related to sending packets along a connection. Method SummaryConnectionEnd getConnectionEnd( ) Returns the end of the connectionwhere the event occurred. CommunicationPacket getPacket( ) Returns thecommunication packet. InfohabitantGuardian getReceiver( ) Returns thereceiver. InfohabitantGuardian getSender( ) Returns the sender.java.lang.String toString( ) List sender, receiver, and communicationpacket as a string.

[0194] org.ist_uie.diet.core.imp.event

[0195] Class EnvironmentEvent

[0196] java.lang.Object

[0197] |

[0198] +-java.util.EventObject

[0199] |

[0200] +-org.ist_uie.diet.core.imp.event.EnvironmentEvent

[0201] public class EnvironmentEvent

[0202] extends java.util.EventObject

[0203] Basic event object for “environment” events.

[0204] See Also:

[0205] EnvironmentListener, Serialized Form Constructor SummaryEnvironmentEvent(BasicEnvironment source, InfohabitantGuardian infohab)EnvironmentEvent(BasicEnvironment source, InfohabitantGuardian infohab,EnvironmentAddress migration_address) Method Summary BasicEnvironmentgetEnvironment( ) InfohabitantGuardian getInfohabitant( )EnvironmentAddress getMigrationAddress( ) Returns the origin/destinationwhen the event is used for a migration event. java.lang.String toString() List an Infohabitant and its migration address.

[0206] org.ist_uie.diet.core.imp.event

[0207] Class InfohabitantEvent

[0208] java.lang.Object

[0209] |

[0210] +-java.util.EventObject

[0211] |

[0212] +-org.ist_uie.diet.core.imp.event.InfohabitantEvent

[0213] public class InfohabitantEvent

[0214] extends java.util.EventObject

[0215] Basic event object for “Infohabitant” events.

[0216] See Also:

[0217] InfohabitantListener, Serialized Form Constructor SummaryInfohabitantEvent(InfohabitantGuardian source, ConnectionEnd near_end,ConnectionEnd far_end, InfohabitantGuardian initiating_infohab,InfohabitantGuardian passive_infohab) An event related to creation anddestruction of an Infohabitant's connection. Method SummaryConnectionEnd getFarConnectionEnd( ) Returns the far end of theconnection. InfohabitantGuardian getInitiatingInfohabitant( ) Returnsthe initiating Infohabitant. ConnectionEnd getNearConnectionEnd( )Returns the near end of the connection. InfohabitantGuardiangetPassiveInfohabitant( ) Returns the passive Infohabitant.java.lang.String toString( ) Determine the Infohabitant that initiatedthe event (so that it can be marked with an asterisk).

[0218] org.ist_uie.diet.core.imp.event

[0219] Class NeighbourhoodEvent

[0220] java.lang.Object

[0221] |

[0222] +-java.util.EventObject

[0223] |

[0224] +org.ist_uie.diet.core.imp.event.NeighbourhoodEvent

[0225] public class NeighbourhoodEvent

[0226] extends java.util.EventObject

[0227] Basic event object for “neighbourhood” events.

[0228] See Also:

[0229] NeighbourhoodListener, Serialized Form Constructor SummaryNeighbourhoodEvent(BasicEnvironment source, EnvironmentAddress address)Method Summary EnvironmentAddress getAddressOfNeighbour( )BasicEnvironment getEnvironment( ) java.lang.String toString( ) List theenvironment address and neighbourhood address.

[0230] org.ist_uie.diet.core.imp.event

[0231] Class RunEvent

[0232] java.lang.Object

[0233] |

[0234] +-java.util.EventObject

[0235] |

[0236] +-org.ist_uie.diet.core.imp.event.RunEvent

[0237] public class RunEvent

[0238] extends java.util.EventObject

[0239] Basic event object for “run” events.

[0240] See Also:

[0241] RunListener, Serialized Form Constructor SummaryRunEvent(java.lang.Object source)

[0242] org.ist_uie.diet.core.imp.event

[0243] Class WorldEvent

[0244] java.lang.Object

[0245] |

[0246] +-java.util.EventObject

[0247] |

[0248] +-org.ist_uie.diet.core.imp.event.WorldEvent public classWorldEvent

[0249] public class WorldEvent

[0250] extends java.util.EventObject

[0251] Basic event object for “world” events.

[0252] See Also:

[0253] WorldListener, Serialized Form Constructor SummaryWorldEvent(World source, BasicEnvironment env) Method SummaryBasicEnvironment getEnvironment( ) World getWorld( ) java.lang.StringtoString( ) List environment address.

[0254] Infohabitants

[0255] Referring to FIG. 3, an Infohabitant is a software agent. As abasic minimum, it is provided with means for communicating with otherInfohabitants. It will also usually be provided with software code forperforming one or more series of operations in use. When an applicationruns using the DIET platform, Infohabitants in the ARC and applicationlayers 1810 will run their code as necessary. In running their code,they will need to communicate with their environment and, via theenvironment, with other Infohabitants. For instance, Infohabitantscommunicate with their environment when they need kernel services, suchas connecting to other Infohabitants or creating other Infohabitants.They need to communicate with other Infohabitants to exchange datamessages. The other Infohabitants might also be in the application layer1810, or they may supply application re-usable services and thus be inthe ARC layer 1805. As far as the Infohabitant is concerned, for thesecommunications to occur, there are a limited number of events that willhappen in support for which it will require a thread in order torespond.

[0256] Infohabitant Naming Scheme

[0257] The primary capability built into every Infohabitant is theability to communicate with each other. Every Infohabitant has a (local)identity consisting of a binary name tag and a binary family tag. Thename tag allows Infohabitants to be uniquely identified within their ownenvironment, and the family tag can be used to look up Infohabitants byfunctionality. Family tags can be used as a shared identifier for agroup of agents, or as an identifier which can be set according to anagreed rule, or as an evolved identifier which externally distinguishesa specific sub-species of adaptive agent.

[0258] A very simple example of an agreed rule is that Infohabitantsconstruct their family tag from a text string. A convention that is usedfor many Infohabitants in DIET is to use the full name of the class(e.g. “org.ist_uie.diet.arc.services.Carrier”) that implements theInfohabitants. It is even possible that Infohabitants of the same class,initialise their family tag differently. For instance, WebPageAnnotationInfohabitants can be created for maintaining comments about webpages.Each such Infohabitant would be responsible for maintaining commentsabout a respective single page. Each such Infohabitant could constructits family tag from the URL of the page that it represents. In this way,if an Infohabitant wants to find out what the comments are about acertain webpage, it can simply generate the family tag from the URL ofthe webpage, and subsequently try to connect to an Infohabitant withsuch a family tag. If this succeeds, it can communicate with theInfohabitant to obtain comments about the webpage. In practice, thefamily tag would be generated from more than the URL alone, to reducethe chance of name clashes with Infohabitants that provide otherweb-page related functionality, e.g. providing links to similarwebpages. A good approach would for instance be to XOR the binaryrepresentation of the URL with the binary representation of theInfohabitant's full classname.

[0259] A simple example of an evolving identifier is where the behaviourof an Infohabitant is controlled by a binary genome. Its family tag canthen partly be constructed from the value of its genome.

[0260] Infohabitants in their own environment perform inter-Infohabitantcommunication by treating Infohabitant identities as addresses. In awider context, Infohabitants are uniquely identified by including as apart of their global identity, the identity of their own environment,and the identity of the World in which that environment resides. Thus,the respective identities of Infohabitants, Environments and Worlds areequivalent to addresses, and herein the terms “identity” and “address”are used synonymously.

[0261] Every Infohabitant has an InfohabitantIdentity that consists oftwo bitstrings, a Name Tag and a Family Tag. The Name Tag can be used toidentify Infohabitants and is randomly initialised by the DIET kernelwhen the Infohabitant is created. As long as the Name Tags aresufficiently long, the probability that two Infohabitants have equalnames is effectively zero. For instance, when tags are 128 bits long,the probability that two or more Infohabitants in a group of one millionhave the same name is 1.5×10⁻²⁶. The advantage of this approach is thatit is decentralised and thus scales well.

[0262] The Family Tag can be used to distinguish between differenttypes, or families, of Infohabitants. It is set by the Infohabitant whenit is created, and remains constant throughout the lifetime of eachInfohabitant.

[0263] Environments provide two ways of looking up Infohabitants. Toconnect to an Infohabitant, it is necessary to specify either a completeidentity or a Family Tag. The former can be used to look up specificInfohabitants whereas the latter can be used to look up Infohabitants byfunctionality. By only providing basic ways of connecting toInfohabitants this can be done quickly (even when there are manyInfohabitants) while still using relatively little memory.

[0264] Three example Infohabitant identities are shown below:

[0265] A: identity=(name=01100101, family=11000101)

[0266] B: identity=(name=1010110011, family=010011)

[0267] C: identity=(name=00010001, family=11000101)

[0268] Here Infohabitant A and Infohabitant C have equal family tags.All name tags are unique, but that is not surprising as these are allinitialised randomly. Note, in real applications tags are typicallylonger (e.g. 128 bits). A name tag and a family tag do not necessarilyhave to be of the same length. Also, the length of name tags and/orfamily tags can be different for different Infohabitants.

[0269] The identity of an Infohabitant is held by anInfohabitantIdentity object, which is maintained by theInfohabitantGuardian proxy (See FIG. 1). By making theInfohabitantGuardian responsible for maintaining the identity instead ofletting the Infohabitant itself do so, Infohabitants are prevented fromchanging their identity during their lifetime.

[0270] The following documents Infohabitantidentity.

[0271] org. is tuie.diet.core

[0272] Class Infohabitantidentity

[0273] java.lang.Object

[0274] |

[0275] +—org.ist_uie.diet.core.InfohabitantIdentity

[0276] public final class Infohabitantidentity

[0277] extends java.lang.Object

[0278] Stores the identity of an Infohabitant. An identity consists of aname tag and a family tag.

[0279] Note: Objects of this class are immutable. Constructor SummaryInfohabitantIdentity(Tagname, Tag family) Method Summary booleanequals(java.lang.Object other) Tag getFamily( ) Identifies the familythat this Infohabitant belongs to.. Tag getName( ) Returns the name forthe Infohabitant.. int hashCode( ) java.lang.String toString( ) Returnsa short representation of this identity. Methods inherited from classjava.lang.Object clone, finalize, getClass, notify, notifyAll, wait,wait, wait

[0280] Constructor Detail

[0281] Infohabitantidentity

[0282] public InfohabitantIdentity(Tag name, Tag family)

[0283] Method Detail

[0284] getFamily

[0285] public Tag getFamily( )

[0286] Identifies the family that this Infohabitant belongs to. It isset on creation of the Infohabitant. It is possible that Infohabitantsof the same Java class have the same family tag, but this does not needto be the case. The tag may evolve over time, allowing the emergence ofnew families/species.

[0287] Returns:

[0288] the family tag

[0289] getName

[0290] public Tag getName( )

[0291] Returns the name for the Infohabitant.

[0292] It is initialised randomly by the environment on creation of theInfohabitant.

[0293] Returns:

[0294] the name tag

[0295] equals

[0296] public boolean equals(java.lang.Object other)

[0297] Overrides:

[0298] equals in class java.lang.Object

[0299] hashCode

[0300] public int hashCode( )

[0301] Overrides:

[0302] hashCode in class java.lang.Object

[0303] toString

[0304] public java.lang.String tostring( )

[0305] Returns a short representation of this identity.

[0306] Note: Different identities can map to the same representation,but this is unlikely. It is always possible to use the tags directly toconstruct a unique representation.

[0307] Overrides:

[0308] toString in class iava.lang.Object

[0309] Event Portal

[0310] The DIET kernel has been designed to be as lightweight aspossible. It provides only essential services, and always in a verybasic way. This helps to make it more scalable, and enables it todeliver its functionality quickly and efficiently. Robustness isexplicitly addressed in the DIET core by directly exposing Infohabitantsto potential failure, for instance in being allocated a thread in orderto run a process or in communications between Infohabitants. This allowsthem to adapt to system load and change their behaviour accordingly.Part of the implementation of this exposure to failure lies in theEventPortal.

[0311] Referring to FIG. 3, for every Infohabitant the kernel implementsan EventPortal. The EventPortal registers every event, for instancesignalling an incoming message, a new connection etc., in respect of itsInfohabitant. As a central point of event notification, the EventPortalcan be used to coordinate the Thread state of an Infohabitant, forexample a Thread may enter the EventPortal's ‘wait for event’ block (seeFIGS. 3 & 11). This means that no more CPU cycles will be used by thisThread until a new event is notified to the EventPortal. The EventPortalallows Infohabitants to use their threads efficiently becauseinformation collected by the EventPortal can be used in deciding whetherthe Infohabitant should continue execution, pause execution, retain itsthread or abandon it and become dormant until a new event occurs. Theway in which the Infohabitant Thread is manipulated according to thestate of the EventPortal is detailed in FIG. 3 and FIG. 11.

[0312]FIG. 3 shows how an EventPortal deals with events external to anInfohabitant. Messages, connection notifications and disconnectionnotifications each constitute an event for which the Infohabitant willneed an allocated thread. The EventPortal provides buffers for each ofthe three types of event and each signalled event will be stored in theappropriate buffer. These comprise a message buffer 310, a connectionnotification buffer 315 and a disconnection notification buffer 320.

[0313] The EventPortal maintains a count of events 305 which have beensignalled to the Infohabitant but not dealt with. As shown in FIG. 3,the Infohabitant has a count of six such events. The six events held inthe buffers as shown can be seen to be five messages in the messagebuffer 310 and a disconnection notification in the disconnectionnotification buffer 320.

[0314] Each of the three buffers also has a counter that tracks how manyattempts have been made to put an item in the buffer that failed(because the buffer was full, see FIGS. 6 and 7). Although theInfohabitant that owns the buffer is not directly notified when thishappens, the counter ensures that the Infohabitant can be aware of theserejections. That is, the presence of the counters ensures that theInfohabitant contains the relevant data which it can access if triggeredto do so for instance for use in debugging of the system. ManyInfohabitants can safely ignore the rejection counters, as their properfunctioning is not affected by it. However, some Infohabitants may needto update their state or perform other actions when events have beenrejected. Such an Infohabitant could for instance check if it hasrejected any events every time it finishes handling an event.

[0315] FIGS. 4 to 10 show various self-explanatory flow charts ofprocesses involving the DIET kernel and its interactions withInfohabitants. FIG. 11 shows the generalised execution flow in relationto events, between the Infohabitant and the kernel. Each Figure showsthe steps of a specific process, as listed in the list of Figures above.The following discusses the specifically event-related aspects of theseprocesses.

[0316]FIG. 6 shows when the kernel signals an event to an InfohabitantsEventPortal. FIG. 11 shows how and when an Infohabitant typically usesthe ability to wait for an event.

[0317]FIG. 4: “create guardian” creates the InfohabitantGuardian (seeFIG. 1) for the Infohabitant. “report failure”: the initiatingInfohabitant is signalled by an exception that the creation failed (whenno exception occurred, the attempt was successful). Creation can failbecause the requested Infohabitant type is not permitted; the requestfor a thread to be reserved failed; the parameters that are used toinitialise the Infohabitant have an invalid value; or when there is anexisting Infohabitant in the environment having the same identity.

[0318]FIG. 5: “trigger termination”: signals the Infohabitant toterminate its execution. Control goes briefly back to the Infohabitant'scode (“Infohabitant terminates”), where the Infohabitant can performsome additional clean up (e.g. close open files). However, since it isalready disconnected from the environment it cannot contact theenvironment or any other Infohabitants. As soon as the Infohabitant'sexecution has finished, control goes back to the kernel which sends itto the destination environment.

[0319]FIG. 8: “notification of target Infohabitant”: as shown in FIG. 6.“report failure”: the initiating Infohabitant is signalled that themessage was not successfully sent.

[0320]FIG. 9: “notification of target Infohabitant”: as shown in FIG. 7.“report failure”: the initiating Infohabitant is signalled that aconnection was not successfully set up. In this example, the kernel isusing the locally unique identity, the Name Tag, together with theFamily tag, of a single Infohabitant in order to select the targetInfohabitant.

[0321]FIG. 10: “notification of target Infohabitant”: as shown in FIG.7. “report failure”: the initiating Infohabitant is signalled that aconnection was not successfully set up. In this example, the kernel isusing the family identity of a set of Infohabitants, the Family Tag, andhas to carry out the extra step of selecting an Infohabitant from thefamily as a target Infohabitant.

[0322] Environments and Services to Infohabitants

[0323] Basic Services

[0324] Referring to FIG. 1, the DIET kernel provides certain elements ofthe DIET platform, by means of a basic environment 100, a set of proxies(the InfohabitantGuardian 105, ConnectionEnd 120), parts of theInfohabitant implementation 110 (particularly the event portal as shownin FIG. 3), Infohabitantidentity 115, and contexts 125 for use inconnections between Infohabitants 110.

[0325] Environments only provide a bare minimum of basic services toInfohabitants. Other services can be built on top of these basicservices, and do not need to be provided by the DIET kernel. Theadvantages of this approach are that the Environment is more suitablefor hosting many Infohabitants and that the implementation of higherlevel services can be adapted to the needs of the specific DIETapplication. The approach is similar to the “micro-kernel” in a systemknown as MADKit (reference given below). Their micro-kernel isintentionally limited as well, although it differs in the services thatit provides.

[0326] The basic services provided by each Environment are:

[0327] New Infohabitants can be created

[0328] Infohabitants can move to another Environment

[0329] Infohabitants can connect to other Infohabitants in theEnvironment.

[0330] The services provided by Environments are unreliable. TheEnvironment provides the services when it can, but fails immediatelywhen it cannot. For example, every Environment can have a strict limiton the number of Threads that it can allocate (this is discussed furtherunder the heading “Allocation of threads” below). This means thatcreation of an Infohabitant or its migration fails when there iscurrently no thread is available. In both cases, the Infohabitant dies.

[0331] The idea of putting a strict limit on certain resources, andthereby making the services that relate to it unreliable, is used atvarious places within the DIET platform. It makes the platform morerobust because it will, for instance, not run out of memory when thesystem load is high. Instead, it makes high system load visible toInfohabitants and forces them to adapt to it.

[0332] Infohabitant Creation

[0333] Referring to FIG. 4, new Infohabitants can be created. To createan Infohabitant, the user specifies the type of Infohabitant to createand the parameters to use. The kernel checks the type of theInfohabitant to ensure that it obeys a few basic rules. It checks thatthe type is an instance of (i.e. a subclass of) the “BasicInfohabitant”class. The “BasicInfohabitant” class is an Infohabitantimp that obeysthe basic rules. Its implementation is such (using normal Java/OOtechniques) that subclasses cannot change this behaviour. The kernelalso assigns a randomly generated name tag to the Infohabitant. This isa simple, efficient mechanism to allocate names that are in practiceunique. The Infohabitant can choose its own family tag, but the kernelensures that the identity of an Infohabitant remains fixed throughoutits lifetime.

[0334] Infohabitant to Infohabitant Connection

[0335] Referring to FIGS. 6, 7 and 8, Infohabitants can connect to otherInfohabitants in the same environment. Once connected, Infohabitants cancommunicate by sending messages or passing additional objects to eachother. By only allowing local connections, Infohabitants can receiveimmediate feedback when sending a message. It was either deliveredsuccessfully, or it was rejected. Referring to FIGS. 9 and 10,connections can be established in only two ways, by specifying either acomplete identity or the family tag of the required Infohabitant. Bothlook-up mechanisms can be implemented and used very efficiently. Morecomplicated directory functionality can be built on top of this basefunctionality and provided by Infohabitants if needed.

[0336] Infohabitant Movement between Environments

[0337] Referring to FIG. 5, Infohabitants can move to anotherenvironment. Infohabitant mobility is useful to make the system moreadaptable to changing circumstances. It allows an Infohabitant to selectfrom various execution environments, depending upon the availability andefficiency of environmental services, and it can help in the formationof neighbourhoods of social interaction between Infohabitants. Thekernel does not guarantee that every migration attempt succeeds. When anInfohabitant wants to move, but the destination environment can notaccept it, for example because it is currently off-line or has reachedits full capacity, the Infohabitant dies.

[0338] Every Environment maintains a list of Environments that are inits Neighbourhood. Neighbourhood relationships are created by the userand can be set up arbitrarily. Typically, neighbouring environments arephysically close (e.g. running in the same Java VM, running on the samecomputer, or running on a nearby computer), however, this need not bethe case.

[0339] The concept of Neighbourhood is used to implement one migrationmechanism. An Infohabitant can request to migrate without specifying theaddress of an Environment to move to. In this case, the Environment willrandomly select one of the Environments in its Neighbourhood and(attempt to) migrate the Infohabitant to it. This mechanism allowslight-weight Infohabitants to sensibly explore the DIET universe,without the need to provide them with the addresses of one or moreEnvironment on their creation.

[0340] (Note: Infohabitants are not restricted in their movement by theEnvironment's Neighbourhood. When an Infohabitant has the address of anEnvironment that is not in the Neighbourhood of the current Environment,it can still directly migrate to the remote Environment.)

[0341] There is no specific event that triggers Infohabitants to move.This depends on the specific type (class) of Infohabitant. E.g.CarrierPigeons are implemented such that they always directly move afterthey have been created (more details below).

[0342] When an Infohabitant migrates to an Environment that is currentlyoffline/full, it is simply not restarted and the Infohabitant isdiscarded. So, Infohabitants cannot do anything after this has happened.However, to minimise the risk of it dying, an Infohabitant can checkbeforehand if the Environment is offline or full. It can, for instance,create a “Scout” Infohabitant. The behaviour of a Scout can be verybasic. On creation it moves to a given remote Environment. When itarrives at the remote Environment, it immediately moves back to itsoriginal Environment. Here it contacts the Infohabitant that created it.The latter Infohabitant then “knows” that the remote Environment wasavailable. This is no absolute guarantee that it still is (it could havegone off-line just after the Scout left), but makes it highly likely.

[0343] It should be noted that the DIET system intentionally does notattempt to provide any absolute guarantees, as this is impossible giventhe nature of the infrastructure—the remote environment can, inprinciple, terminate at any moment.

[0344] For both communication and migration the kernel support isminimal. It can therefore be implemented very efficiently. It alsoallows more sophisticated functionality to be build on top of it,implemented in a way best suited to the conditions in which it is used.The minimalistic implementation is partly achieved because the kernelonly fulfils any request when it can easily do so, but immediately failswhen it cannot. It has the additional advantage that it implicitlyforces Infohabitants to take the effect of their actions on theirexecution environment into account.

[0345] Another feature of the kernel is that explicit limits can beimposed on several elements in the system such as the number of threadsthat are in use and the size of the message buffer of everyInfohabitant. These limits help to make the DIET platform more robustwith respect to system load. For example, when a new message arrives atan Infohabitant whose incoming message buffer is full, it is simplyrejected. This mechanism ensures that the system will not run out ofmemory when one or more Infohabitants receive more messages than theycan handle. It also exposes the sending Infohabitant to the congestionso that it can adapt its behaviour accordingly.

[0346] These limits can be set by the user. For instance they can be setwhen the DIET software starts running (while the Environments arecreated), but some (e.g. the number of threads available) could easilybe changed (by the user) while the system is running. The ThreadPoolwaits with creating Threads until they are first needed (so initiallythere are as many Threads as there are Threads in use). However, whenthe demand on Threads decreases, the ThreadPool may hang on to theThread instead of discarding it (for sake of efficiency—there is acertain cost associated with creating Threads), as is shown in FIG. 2.It means that there can be more Threads than there are Threads currentlyin use.

[0347] Another limit that the kernel can set is the maximum number ofConnections that every Infohabitant can own. An Infohabitant “owns” aconnection when it was the one that created it. This limit affects the“number of available connections” mentioned in FIG. 12. These are alllimits which can be imposed by the kernel.

[0348] The kernel has also been designed to support lightweightInfohabitants. The minimal requirements by an Infohabitant on systemresources such as memory and CPU use is very low. One interestingfeature is that Infohabitants can temporarily give up their thread whenthey do not need it. When an external event occurs, e.g. a messagearrives, the kernel attempts to give it a thread again so that it canhandle the message.

[0349] Use of proxies

[0350] Infohabitants do not have a direct reference to theirEnvironment, nor do they have direct references to each other.

[0351] The InfohabitantGuardian proxies 105 ensure that their respectiveassociated Infohabitants obey the constraints of the architecture. Forinstance, an InfohabitantGuardian proxy prevents its Infohabitant 110from having access to more than one Environment at once, and alsomaintains its Infohabitant's identity, to ensure that the identityremains fixed throughout the Infohabitant's lifetime. See FIG. 1 fordetails. Here InfohabitantImp is the implementation of the Infohabitant.Some of its functionality is provided by the kernel (e.g. there is codeto ensure that every Infohabitant implements the behaviour shown inFIGS. 6 and 7), but most is specific to the Infohabitant's function andtherefore not implemented by the kernel. TABLE 1 Summary of thecomponents and functionality provided by the InfohabitantGuardian proxyVariables/components Functionality Reference to Environment Provides theInfohabitant access to the basic services provided by the EnvironmentReference to InfohabitantImp (the actual Infohabitant) Reference toInfohabitantIdentity List of Connections Maintains the Infohabitant'sconnections Number of available connections List of Listeners Maintainsa list of Listeners and notifies them when connections are created,rejected and destroyed (optional: Basic resource accounting) Referenceto ListenerCookie

[0352] Table 1 provides some additional detail about theInfohabitantGuardian proxy, also referred to simply as theInfohabitantGuardian, which in accordance with the present inventionforms part of a means for communicating of its associated Infohabitant.The functionality it provides is now examined in some more detail.Firstly, an Infohabitant can use its InfohabitantGuardian proxy toaccess the services provided by the Environment. This is the only way anInfohabitant can access these services. The DIET kernel can thereforeeasily prevent an Infohabitant from accessing the Environment bydisabling its InfohabitantGuardian proxy. This, for instance, happenswhen the Infohabitant wants to migrate (see “a)” of FIG. 5). Secondly,the InfohabitantGuardian proxy maintains all of its Infohabitant'sconnections, as well as a value for the number of new connections it iscurrently allowed to initiate in response to requests from itsInfohabitant. This enables an InfohabitantGuardian proxy to check if itsassociated Infohabitant can create a connection before forwarding therequest to the Environment, and furthermore enables theInfohabitantGuardian proxy automatically to destroy all connections whenits Infohabitant is removed from the Environment. Thirdly, theInfohabitantGuardian proxy also maintains a list of listeners that itnotifies whenever a connection is created, rejected or destroyed.Objects interested in these events can add themselves as a Listener tothe InfohabitantGuardian proxy for the Infohabitant they want toobserve. One noteworthy feature is that for objects to register as aListener, they need to provide an additional reference to aListenerCookie. If their ListenerCookie is not equal to the onemaintained by the InfohabitantGuardian, their request is ignored. Thismechanism can be used to prevent Infohabitants from adding themselves asa listener. This is necessary, because when Listeners are notified theyreceive details about the event that need to be hidden fromInfohabitants for the system to remain secure. So, in practice, only thedebugging and visualisation tools are given the ListenerCookie, but itis hidden from all Infohabitants. Fourthly, in a DIET platform that usesresource accounting, the InfohabitantGuardian is a convenient place tocharge every Infohabitant for the services it uses. One advantage isthat it hides these details from the Environment whose implementationcan therefore be substantially the same for a non-resource accountingand a resource accounting DIET kernel. FIG. 12 shows how all thesedifferent functions relate. It shows how the InfohabitantGuardianhandles a request to set up a new connection.

[0353] When an InfohabitantGuardian receives a connection request fromits associated Infohabitant, it first determines if its associatedEnvironment is still hosting its Infohabitant. If its Infohabitant isnot still hosted, the InfohabitantGuardian terminates its Infohabitant'sThread. Otherwise, it determines from its internal records if itsInfohabitant has the capacity to initiate a further connection, i.e.whether the number of current connections is less than the maximumpermitted. If its Infohabitant does not have this capacity, it isnotified by the InfohabitantGuardian of the failure of its request.Otherwise, the InfohabitantGuardian makes a request of the associated(hosting) Environment to form a connection between its Infohabitant,also referred to as the requesting Infohabitant or just the requester,and the target Infohabitant, also referred to as just the target.

[0354] The hosting Environment then checks that the identity of therequesting Infohabitant and the identity of the target Infohabitant arenot equal. If they are equal, the requesting Infohabitant is notified bythe hosting Environment of the failure of its request, otherwise thehosting Environment tries to acquire the reference to theInfohabitantGuardian associated with the target Infohabitant. If thereis no InfohabitantGuardian associated with the identity of the targetInfohabitant, the requesting Infohabitant is similarly notified of thefailure of its request. Otherwise, the Environment makes a request ofthe requester's InfohabitantGuardian to negotiate a connection with thetarget InfohabitantGuardian.

[0355] The requester's InfohabitantGuardian then constructs twoConnectionEnds, one intended for the requester, referred to as therequester ConnectionEnd, and one for the target, referred to as thetarget ConnectionEnd, and notifies each ConnectionEnd of the identity ofthe other, reciprocal ConnectionEnd. Finally, it acquires the targetInfohabitant from the target's InfohabitantGuardian, and makes a requeston the target Infohabitant to accept the target ConnectionEnd. Thetarget ConnectionEnd may be rejected because the target Infohabitant'sEventBuffer is full, or because a Thread could not be dynamicallyallocated to the target Infohabitant or because the target Infohabitanthas previously selected to reject all connections. If the targetConnectionEnd is rejected, the requesting Infohabitant is notified ofthe failure of its request. Otherwise, a ConnectionEvent is pushed intothe target Infohabitant's respective EventBuffer, containing a referenceto the target ConnectionEnd, an event which will be handled in duecourse when the target Infohabitant removes that event from its buffer,and the requester ConnectionEnd is returned to the requester, thuscompleting the successful negotiation of the Connection.

[0356] The same procedure is used when the requester identifies thetarget by its family tag instead of its unique name tag. This time thelookup by family tag returns a list of individuals of the given familytag, and a single Infohabitant (guaranteed to be different from therequester) is chosen from this list.

[0357] The ConnectionEnd proxy (also shown in FIG. 1) allowsInfohabitants to communicate without directly referencing each other.This offers every Infohabitant basic protection against maliciousInfohabitants. TABLE 2 Summary of the components and functionalityprovided by the ConnectionEnd proxy Variables/components FunctionalityReference to InfohabitantGuardian Reference to other ConnectionEndProvides the Infohabitant with ability to communicate with otherInfohabitant Reference to Context Provides Infohabitant access toContext Flag that controls if connection is enabled List of ListenersMaintains a list of Listeners and notifies them when messages are sent,accepted, and rejected. (optional: Basic resource accounting) Referenceto ListenerCookie

[0358] Table 2 provides some additional detail about the ConnectionEnd.It also supports listeners. These listeners receive events when messagesare being sent, received, accepted and rejected. Once again, Listenersneed to “know” what the ListenerCookie is to register themselves (onceagain for security, it for instance prevents malicious Infohabitantscontrol over other Infohabitants). FIG. 13 shows how the ConnectionEndcombines several of its functions when it is used to send messages.

[0359] Both the InfohabitantGuardian and the ConnectionEnd proxy arededicated to a single relationship (either between an Infohabitant andits environment, or between two Infohabitants). This has severalbenefits. Firstly, it enables the kernel to selectively and efficientlydisable certain connections or disallow specific Infohabitants access toan environment. Secondly, it can be used to efficiently observe theinteractions with specific Infohabitants and their Environment or theinteractions between pairs of Infohabitants, using the Listener designpattern as described in Erich Gamma, Richard Helm, Ralph Johnson andJohn Vlissides. “Design patterns: Elements of Reusable Object-OrientedSoftware”, 1995, Addison-Wesley. Thirdly, it also enables Infohabitantsto efficiently associate a state (a so-called Context) with each oftheir connections.

[0360] The concept of Proxies is a known design pattern. Use of proxiesfor access control, dynamic revocation and usage metering is known. IBMAglets for instance uses proxies for security and location transparency.The MADKit development kit has also been designed such that only thekernel has direct reference to agents. Voyager uses proxies fortransparent access to remote objects. Adjanta uses proxies to providesecure access to “resources”.

[0361] Publications relevant to some of the material mentioned above areas follows: Gutknecht, O & Ferber, J 1997 MadKit: Organisingheterogeneity with groups in a platform for multiple multi-agentsystems. Technical Report 97188, LIRMM. 161, rue Ada—Montpellier—France,December 1997.

[0362] For Aglets, a central reference is a book:

[0363] Lange, D. & Oshima, M. 1998 Programming and Deploying MobileAgents with Java Aglets. Peachpit Press, Berkeley.

[0364] The following paper gives an overview of the Aglet API:

[0365] Lange, D. & Oshima, M. 1998 Mobile Agents with Java: the AgletAPI. World Wide Web Journal.

[0366] The following paper refers to Aglets identities, proxies andcontexts in the context of security:

[0367] Karjoth, G., Lange, D. B. & Oshima, M. 1997 A security model forAglets. IEEE Internet Computing July-August 1997, 68-77.

[0368] Adjanta: the following paper gives an overview of the system:

[0369] Karnik, N. M. & Tripathi, A. R. 1998 Agent Server Architecturefor the Ajanta MobileAgent System. In: Proceedings of 1998 InternationalConference on Parallel and Distributed Processing Techniques andApplications (PDPTA'98), Las Vegas, July 1998.

[0370] and this paper goes into some detail on the use of proxies:

[0371] Tripathi, A. & Karnik, N. 1998 Protected resource access formobile agent-based distributed computing. In: Proceedings of ICPPWorkshop on Wireless Networking and Mobile Computing, Minneapolis,August 1998.

[0372] The Arc Layer 1805

[0373] The Application Reusable Components layer 1805 provides servicesthat are typically useful to applications built on top of the DIETplatform. They can be used whenever this is useful, but can be ignoredor replaced by alternative implementations.

[0374] Above the core layer 1800 the DIET software platform can includea range of components. For instance, these might draw upon ecologicaland evolutionary inspiration, as well as machine learning and othermechanisms, in order to provide diverse sources of flexibility tofacilitate the adaptation of DIET agents to changing circumstances. Thislayer will also include the elements that support a range of informationmanagement and manipulation applications.

[0375] The ARC layer 1805 also provides Infohabitants that offerservices not directly provided by the DIET kernel. Infohabitants canaccess these services through their family tags. For example, the ARClayer 1805 defines a CarrierPigeon Infohabitant that can be used todeliver messages to Infohabitants in a different environment and thusprovides basic remote communication. Other Infohabitants defined in theARC layer 1805 can use these CarrierPigeons to offer various moresophisticated ways to communicate remotely.

[0376] More precisely, the behaviour of a basic CarrierPigeon is asfollows. On creation it is given the address of an Infohabitant (whichresides in a different Environment), a respective family tag, and amessage. It migrates to the remote Environment, and when this has beensuccessful, it delivers the message to the given Infohabitant. A moresophisticated implementation may wait for a reply, and return this replyto the Infohabitant that created the Infohabitant to send the originalmessage.

[0377] The above explanation describes one basic implementation ofremote communication. A basic implementation of Multi-cast communicationis as follows. When an Infohabitant wants to multi-cast messages, itcalls on, or creates via the Environment, a “MultiCast” Infohabitant andprovides it with the identities of all target Infohabitants. TheMultiCast sends all messages it receives from the former Infohabitant toall other Infohabitants. Any replies are returned to it by theMultiCast, optionally prepended by a unique identifier to distinguishthe Infohabitant that sent the reply. Once again, more sophisticatedbehaviours could be implemented, e.g. a MultiCast Infohabitant could beresponsible for several multi-cast relations.

[0378] Service Provision by Infohabitant

[0379] In DIET systems, many services that are commonly found in thecore of known multiagent systems, are provided by Infohabitants instead.Two examples are remote communication (communicating with Infohabitantsin different Environments) and multi-cast communication (sendingmessages to groups of Infohabitants) as described above.

[0380] Service Provision: Middleman Infohabitant

[0381] Referring to FIGS. 14 and 15, this section describes a simpleexample of service provision using an Infohabitant implementation calleda “MiddleMan” Infohabitant. It illustrates how Contexts can be usedeffectively. The behaviour of the MiddleMan Infohabitant described hereis basic. It allows Infohabitants to communicate indirectly with otherInfohabitants. It can, for instance, be used by Infohabitants that wantto hide their identity for some reason (e.g. privacy). In this example,the Infohabitant that sets up a connection by way of the MiddleMan isreferred to as a Client, whereas the other Infohabitant is referred toas a Server. After a Client has connected to the Middleman, it firstsends a message identifying the Server it wants to connect to. TheMiddleMan then sets up a connection to the Server. From then on, anymessage the Client sends to the MiddleMan is directly forwarded to theServer. Similarly, any messages the server sends in reply are passedback to the Client.

[0382]FIG. 14 shows how the MiddleMan can implement its behaviour.Whenever it handles a new connection (which by definition is a Client),all it does is associate a MiddleMan specific context with it, which hasan empty forwarding address. Whenever it receives a message, it firstchecks the Context associated with the connection. If the forwardingaddress is empty, it means it is the first message sent by the Client.It interprets the message and creates a connection to the desired Server(it should be noted that all error handling has been omitted for sake ofsimplicity). When it has done so, it updates both Contexts. For theContext associated with the connection to the Client, it sets theforwarding address to the newly created connection to the Server. Forthe Context associated with the connection to the Server, it sets theforwarding address to the connection associated with the Client.

[0383] When the forwarding address is non-empty, it means that it is amessage which it can forward directly. Without distinguishing if themessage is from a Client or a Server, it forwards the messageautomatically to the appropriate other Infohabitant using the forwardingaddress. This simple behaviour is sufficient for the MiddleMan to beable to handle multiple Client-Server relationships at once.

[0384]FIG. 15 shows an example configuration. Here a single MiddleMan isused for maintaining three Client-Server relationships. Note that twoClients (ClientA and ClientB) communicate with the same Server. This ishandled without any problem, as the forwarding address associated withthe connection tells to which Client any incoming message needs to go.

[0385] The Infohabitants blocks shown in FIG. 15 are Infohabitantimps.The Figure does not show the InfohabitantGuardians (for sake ofsimplicity).

[0386] It is important to realise that the implementation of theMiddleMan does not maintain any reference to its connections. (ItsInfohabitantGuardian does, but these cannot be accessed by theMiddleMan's Infohabitantimp.) It does not need to know the Clients andServers that it is connected to. Whenever it needs to handle a newconnection or an incoming message, all it needs to know is stored in theassociated Context. In fact, this basic version of the MiddleMan doesn'tstore any “Infohabitant specific components” (see FIG. 3).

[0387] The functionality of the MiddleMan described here is very basic.Typically, it would be more sophisticated. For instance, instead ofletting Clients specify the Server directly, they could let the Clientdescribe the properties of the service it requires. The MiddleMan couldthen try to find a Server that best meets these requirements. In thiscase, the MiddleMan would typically maintain information about thevarious Servers it knows of. For each Server it would maintain a fewbasic properties such as its identity and published capabilities.However, it could also track dynamic properties, such as how quickly theserver typically responds. It can easily track these, as all requestsfrom Clients and replies from Servers are handled by the MiddleMan. Thetable that maintains all this Server specific information would be anexample of an Infohabitant specific component.

[0388] In the above, the Middleman relies on a Context object. The roleof a context object is to help an agent efficiently maintain a‘transaction state’ associated with each connection it opens forcommunication to other agents. The efficiency arises from the waymessages are passed from agent to agent. The agent's notification of anincoming message event, or disconnection event on an existingconnection, passes a reference to its ConnectionEnd. The ConnectionEndcan be directly used to store and obtain a context object, without theuse of tables and the overhead of accessing them. No prescription ismade regarding the form of this object, (Context is an empty interface),but agents use the object to ‘keep track’ of what is happening with aconnection. This means that they can rapidly call up a current statefrom which they know the action required on receiving a message, orwhich tells them how to tidy up when a connection has been disposed of.

[0389] Service Provision: Mirror Infohabitant

[0390] An alternative mechanism for providing remote communicationbetween environments uses Mirror Infohabitants. Mirror Infohabitants useCarrierPigeon Infohabitants to transport the actual messages betweenInfohabitants, but hide as much as possible of the remote communicationfrom the Infohabitants themselves. Thus, as is explained below, anInfohabitant can communicate with Infohabitants in remote environmentsin the same way as communicating to Infohabitants in its ownenvironment.

[0391] In short, every Mirror Infohabitant acts in one environment as a“remote representative” for an Infohabitant in a different environment.All messages that are sent to a Mirror Infohabitant are delivered to theInfohabitant it represents. Any connections that are made to a MirrorInfohabitant result in a connection to the Infohabitant it represents.This involves the automatic creation of another Mirror Infohabitant,which represents the Infohabitant that initiated the connection, and isexplained in greater detail in the following example.

[0392] An Infohabitant A resides in an Environment 1, and can provide acertain service X which involves receiving query messages from otherInfohabitants in the Environment 1, performing the service X, andsending a reply in return. It has a binary family tag, as describedabove, which identifies it as a Service Provider of the service X toother Infohabitants. For convenience, in this example, the actual binaryfamily tag of the Infohabitant A is represented by the term,ServiceProviderX.

[0393] To make its service X available to Infohabitants in anEnvironment 2, the Infohabitant A creates a mirror of itself, MirrorInfohabitant MA. To do this, the Infohabitant A sends acreateInfohabitant request message to its InfohabitantGuardian proxy105, containing, inter alia, the type of the requested Infohabitant,Mirror; the identity of the Infohabitant that the newly created mirroris to represent, in this case, A; the identity of the destinationenvironment, the Environment 2; and a Family flag, referred to herein asa specifier, specifying that the newly created mirror is to have thebinary family tag of the Infohabitant A, as opposed to a non-specific,all-zero, family tag.

[0394] The InfohabitantGuardian responds by sending to the Environment1, a message containing the information received in the request message.

[0395] Upon creation by the Environment 1, the Mirror Infohabitant MAimmediately moves to the Environment 2.

[0396] Suppose now that an Infohabitant B resides in the Environment 2and wants to use the service X. To do so, it asks itsInfohabitantGuardian for a connection to a Service Provider Infohabitanthaving a binary family tag, ServiceProviderX. The InfohabitantGuardiansends a request to the Environment 2 for the local identity, i.e. binaryname tag, of a local Service Provider Infohabitant for that service X.The Environment 2, which had previously registered the arrival of theMirror Infohabitant MA as a Service Provider Infohabitant for theservice X, responds to that request by sending a reply message to theInfohabitantGuardian for Infohabitant B containing a reference to theInfohabitantGuardian for the Mirror Infohabitant MA. TheInfohabitantGuardian for the Infohabitant B now provides that referenceto a ConnectionEnd proxy, newly created for this connection, which thenrequests the InfohabitantGuardian for the Mirror Infohabitant MA toestablish a connection between itself and a corresponding ConnectionEndproxy for the Mirror Infohabitant MA and also newly created for thisconnection.

[0397] In a first embodiment of the present invention, the MirrorInfohabitant MA responds to the establishment of that connection withthe Infohabitant B via the newly created ConnectionEnd proxies byrequesting the creation of a mirror, Mirror Infohabitant MB, for theInfohabitant B, and specifying that the Mirror Infohabitant MB is tomigrate to the Environment 1, i.e. where the creator (Infohabitant A) ofthe Mirror Infohabitant MA is resident. This is done in an analogousmanner to the creation of the Mirror Infohabitant MA, but this time theFamily flag specifies that the newly created mirror is to have thenon-specific family tag rather than the binary family tag of theInfohabitant B, and the Mirror Infohabitant MA specifies the identity ofthe Infohabitant that it is representing, namely Infohabitant A.Furthermore, the Mirror Infohabitant MA provides in that request afamily tag to be used by the Mirror Infohabitant MB for creatingCarrierPigeon Infohabitants for carrying messages to the MirrorInfohabitant MA. This family tag is the same unique family tag that theMirror Infohabitant MA uses for creating its own CarrierPigeonInfohabitants, referred to hereafter as the MA-specific CarrierPigeonfamily tag. In this way, as described below, the Mirror Infohabitant MAdistinguishes between messages carried by CarrierPigeon Infohabitantsfrom the Mirror Infohabitant MB resident in the Environment 1, andmessages that it receives from Infohabitants resident in the Environment2, i.e. local messages that need to be forwarded from the Environment 2to the (remote) Environment 1. Similarly, the Mirror Infohabitant MBdistinguishes between messages carried by CarrierPigeon Infohabitantsfrom the Mirror Infohabitant MA resident in the Environment 2, andmessages that it receives from the Infohabitant A resident in theEnvironment 1 that need to be forwarded to the Mirror Infohabitant MAresident in the Environment 2.

[0398] The Mirror Infohabitant MB is set-up to reject any newconnections from Infohabitants that do not have the MA-specificCarrierPigeon family tag. As a result, it will not accept any localmessages from Infohabitants other than the Infohabitant A and it willreject any fraudulent CarrierPigeon, i.e. one that does not have theMA-specific CarrierPigeon family tag.

[0399] In this embodiment the MA-specific CarrierPigeon family tag wasselected and provided to the Mirror Infohabitant MA by the InfohabitantA. In a variant, the Mirror Infohabitant MA generates its ownMA-specific CarrierPigeon family tag.

[0400] Returning now to the request by the Mirror Infohabitant MA forthe creation of a mirror for the Infohabitant B, the Environment 2, uponreceipt of that request, creates the Mirror Infohabitant MB, whichimmediately moves to the Environment 1, and there it establishes aconnection via respective ConnectionEnd proxies, as described above,with the Infohabitant A.

[0401] When the Infohabitant B sends any subsequent message over theexisting connection to the Mirror Infohabitant MA (the Service Providerfor the service X), i.e. a message needing to be forwarded to the MirrorInfohabitant MB now resident in the Environment 1, the MirrorInfohabitant MA detects that the family tag of the Infohabitant fromwhich that message was received, i.e. Infohabitant B, is not its ownMA-specific CarrierPigeon family tag, and that therefore the messageneeds to be forwarded to the remote environment of its creatorInfohabitant, i.e. the Environment 1.

[0402] The Mirror Infohabitant MA responds to receipt of this subsequentmessage by creating a CarrierPigeon Infohabitant with the MA-specificCarrierPigeon family tag. To do this, the Mirror Infohabitant MA firstmodifies the message that it received from the Infohabitant B, acting asa client with respect to the Mirror Infohabitant MA, by appending aunique client connection identifier (CCI) which specifies the connectionat the Mirror Infohabitant MB that the message needs to be delivered to.The Mirror Infohabitant MA now sends a createInfohabitant message to itsInfohabitantGuardian containing, inter alia, the Infohabitant type,CarrierPigeon, the destination address for the newly createdCarrierPigeon Infohabitant, i.e. the identity of the Mirror InfohabitantMB, the MA-specific CarrierPigeon family tag, and the modifiedsubsequent message. The InfohabitantGuardian then communicates with itsenvironment, Environment 2, to effect the actual creation of therequested CarrierPigeon Infohabitant, and the newly createdCarrierPigeon Infohabitant immediately moves to the Environment 1,establishes a connection with the Mirror Infohabitant MB, delivers themodified subsequent message to the Mirror Infohabitant MB overrespective ConnectionEnd proxies, which constitutes indirect delivery ofthe message to the Infohabitant A, and sends a destroyMe message to theEnvironment 1. The Mirror Infohabitant MB first strips off the appendedCCI, and then forwards the actual subsequent message to the InfohabitantA using the existing connection. This subsequent message can be aninitial service request message, or any message in accordance with theparticular message set of that service.

[0403] Thus it will be appreciated that each Mirror Infohabitant usesthe family tag of a connecting CarrierPigeon Infohabitant to distinguishthat it is in respect of a message from the remote environment where theInfohabitant it represents resides, as opposed to a local message thatneeds to be forwarded to that remote environment.

[0404] The manner in which Infohabitants detect this family tag will nowbe described briefly. Whenever a new connection is set up, anInfohabitant is passed the ConnectionEnd proxy corresponding to its sideof that specific connection. Similarly, when an Infohabitant is notifiedof an incoming message, it is not only provided with the message, butalso given the ConnectionEnd proxy where it received the message.

[0405] Taking the example of the Infohabitant B and the MirrorInfohabitant MA, to obtain the identity of the remote Infohabitant Bthat has initiated that connection, the Mirror Infohabitant MA invokes agetIdentityo method of the ConnectionEnd proxy, which maintains areference to the ConnectionEnd proxy at the other end of thatconnection, which in turn maintains a reference to theInfohabitantGuardian for Infohabitant B, which supplies the identity ofthe Infohabitant B. As a result of the establishment of that connection,the Mirror Infohabitant MA is now able to send messages to and receivemessages from the Infohabitant B.

[0406] The Infohabitant A uses the same connection on which it receivedthe subsequent message to send a reply message to the MirrorInfohabitant MB. In like manner, the Mirror Infohabitant MB firstmodifies the reply message by appending a CCI to specify the connectionat the Mirror Infohabitant MA that the message needs to be delivered to,and then creates a CarrierPigeon Infohabitant having the MA-specificCarrierPigeon family tag, which immediately moves to Environment 2,makes a connection with the Mirror Infohabitant MA, delivers to theMirror Infohabitant MA the modified reply message, and sends a destroyMemessage to the Environment 2. The Mirror Infohabitant MA checks thefamily tag of the received message, recognises that it is its ownMA-specific CarrierPigeon family tag and hence that the received messagehas come from a Mirror Infohabitant that it had created and migrated andtherefore needs to be delivered to a local Infohabitant. So, the MirrorInfohabitant MA strips the appended CCI from the received modified replymessage, retrieves the CCI, and then forwards the actual reply messageto the Infohabitant B by means of that specified existing connectionbetween the Mirror Infohabitant MA and the Infohabitant B.

[0407] The use of the CCI to specify the connection at a MirrorInfohabitant that the message needs to be delivered to is important to aMirror Infohabitant which advertises a service provided by its creatorInfohabitant, since there may be many Infohabitants (clients) in itsenvironment which have concurrent connections with that MirrorInfohabitant. For example, further Infohabitants C, D, etc., (not shown)in the Environment 2 may also be sending query messages via the MirrorInfohabitant MA and respective Mirror Infohabitants MC, MD, etc. Thus,when, say the Mirror Infohabitant MC, receives a message from theInfohabitant A, it appends an appropriate CCI to enable the MirrorInfohabitant MA to determine which of its concurrent connections thatmessage is to be delivered to. It will be appreciated thatCarrierPigeons from the respective Mirror Infohabitants MC, MD, etc.will all have the same MA-specific CarrierPigeon family tag. It willalso be appreciated that each of the respective Mirror Infohabitants MC,MD, etc. has only one local connection, i.e. a connection to theInfohabitant A, so, if desired, the operation of a pair of MirrorInfohabitants, e.g. MA and MB, can be asymmetrical in that the MirrorInfohabitant MA need not append a CCI, since the Mirror Infohabitant MBhas only one connection, and does not need a CCI to distinguish betweena plurality of connections. However, for convenience, all the MirrorInfohabitants operate in the same manner. In variants, the MirrorInfohabitant MA is responsive to incoming messages from Infohabitantsnot having its own MA-specific CarrierPigeon family tag, to send theactual message without appending a CCI.

[0408] Malicious Infohabitants cannot pretend to be Mirrors created andmigrated by the Mirror Infohabitant MA, and send CarrierPigeons to theMirror Infohabitant MA, because they will not know the MA-specificCarrierPigeon family tag. So, the mirror-to-mirror inter-communicationvia CarrierPigeons is quite secure.

[0409] If the Infohabitant B, after receiving a reply message from theInfohabitant A, decides that it no longer needs the services of theInfohabitant A, it disconnects from the Mirror Infohabitant MA. As thereis now no need for the Mirror Infohabitant MB, it can be destroyed.Therefore, when the Infohabitant B disconnects from the MirrorInfohabitant MA, the Mirror Infohabitant MA will create a CarrierPigeonwith the MAspecific CarrierPigeon family tag, and a message in the formof a “destroy” command. When the Infohabitant MB receives this messagefrom the CarrierPigeon, it interprets the message and destroys itself.The Environment 1 updates its record of resident Infohabitants andensures that the connection to the Infohabitant A is disconnected.Similarly, should the Infohabitant A disconnect from a mirror created byits Mirror Infohabitant MA, for example the Mirror Infohabitant MB, theMirror Infohabitant MB will send a CarrierPigeon to the MirrorInfohabitant MA with a “disconnect” command and a unique identifier forthe connection between the Mirror Infohabitant MB and the MirrorInfohabitant MA. On receipt of this message, the Mirror Infohabitant MAwill disconnect the connection to the Infohabitant B. It will, however,not necessarily destroy itself, as the Infohabitant A may still want tohave its services available to other Infohabitants in Environment 2.

[0410] In an alternative embodiment of the present invention, the MirrorInfohabitant MA does not respond to the establishment of that connectionwith the Infohabitant B via the newly created ConnectionEnd proxies byrequesting the creation of a mirror, Mirror Infohabitant MB, for theInfohabitant B. Instead, the Mirror Infohabitant MA waits for the firstmessage from the Infohabitant B, which will be the initial servicerequest message, and then requests the creation of the MirrorInfohabitant MB. This request will contain the initial service requestmessage, which the created Mirror Infohabitant MB will carry in asimilar manner to a CarrierPigeon Infohabitant, as described above. Thenewly created Mirror Infohabitant MB immediately moves (migrates) to theEnvironment 1, carrying that initial service request message, and thereit connects to the Infohabitant A, via respective ConnectionEnd proxies,and forwards that message over the newly created connection to theInfohabitant A, which constitutes direct delivery of the message to theInfohabitant A.

[0411] In response to the receipt at the Mirror Infohabitant MA of anysubsequent query message from the Infohabitant B over the establishedconnection, the Mirror Infohabitant MA requests the creation of aCarrierPigeon Infohabitant, as described above, for carrying thatsubsequent message to the Environment 1 and delivering it the MirrorInfohabitant MB, which will forward it to the Infohabitant A.

[0412] The above example shows how remote communication is made easy.The Infohabitant A sets up the ability to communicate remotely bycreating a Mirror Infohabitant MA. After it has done so, the rest of theremote communication is hidden from the Infohabitants which use theInfohabitant A's service X. The Infohabitant A can treat any remoterequests in the same way that it treats requests from Infohabitants inits own environment. Thus, the use of the Mirror Infohabitant MA inEnvironment 2 enables the Infohabitant B to use the service X withoutbeing aware that the service X was actually provided by an Infohabitantin a remote environment.

[0413] It will be instructive for the reader to have further details ofthe use of the nonspecific family tag instead of the binary family tag.When the Mirror Infohabitant MA created the mirror, Mirror InfohabitantMB, no notification was sent to the Infohabitant B. Consequently, theInfohabitant B is unaware of the existence of the Mirror InfohabitantMB, and in the case that the Infohabitant B itself was a serviceprovider for, say, a service Y, the presence in the Environment 1 of theMirror Infohabitant MB having a binary family tag, ServiceProviderY,would mean that the Infohabitant B was, unknowingly, offering itsservice Y to Infohabitants in the Environment 1. The use of thenon-specific family tag thus prevents the Environment 1 from respondingto a request from an Infohabitant for connection to a Service ProviderInfohabitant having a binary family tag, ServiceProviderY, by making aconnection to the Mirror Infohabitant MB. It will be appreciated thatthe form of the non-specific family tag is not limited to the all-zerosof this example, but can be any combination of ones and zeros which isnot already in use as the binary family tag of a Service ProviderInfohabitant.

[0414] In a variant of this example, instead of the CarrierPigeonInfohabitant destroying itself after delivering the query message to theMirror Infohabitant MB in the Environment 1, it starts a timeout andwaits for a reply message. When it receives a reply message from theInfohabitant A, or upon expiry of the timeout, it then moves toEnvironment 2, delivers the reply message, actual or null, to the MirrorInfohabitant MA and then sends a destroyMe message to the Environment 2.In further variants, instead of destroying the CarrierPigeon (a) when ithas delivered its message to the Mirror Infohabitant MB or (b) when ithas delivered its message (actual or null) to the Mirror InfohabitantMA, depending upon the particular variant as described above, theCarrierPigeon is stored in its current environment and is available forre-use. In a still further variant, when the Infohabitant B terminatesthe connection to the Mirror Infohabitant MA, the Mirror Infohabitant MAsends a trigger to the CarrierPigeon Infohabitant, which responds bysending a destroyMe message to the Environment 2.

[0415] Mirror Infohabitants can be used for remote communication whenthe specific target Infohabitant in the remote environment is alreadyknown. Thus, in an alternative embodiment of the present invention,suppose that an Infohabitant D is a Service Provider for a service Y,i.e. has a ServiceProviderY family tag, that it resides in theEnvironment 1 and wants to communicate with an Infohabitant E thatresides in the Environment 2. To do so, the Infohabitant D creates aMirror Infohabitant ME in its own environment, i.e. the Environment 1.In the createInfohabitant request it specifies: the type ofInfohabitant, Mirror; the address of the Infohabitant it shouldrepresent (this is the identity of the Infohabitant, i.e. the name andfamily tag of Infohabitant E, and the address of the environment wherethe Infohabitant E resides, i.e. the Environment 2); the environmentwhere the Mirror Infohabitant ME should reside, i.e. the Environment 1;and the Family flag specifying that it should use a nonspecific familytag. This last requirement is because the Infohabitant D is to be theonly Infohabitant to use the Mirror Infohabitant ME. Other Infohabitantsin the Environment 1 must not accidentally set up a remote connection tothe Infohabitant E when they are looking for a Service Provider Y.

[0416] When the Environment 1 creates the Mirror Infohabitant ME, itreturns the identity of the newly created Infohabitant. The InfohabitantD now uses the returned identity to make a connection to MirrorInfohabitant ME, and in response, the Mirror Infohabitant ME creates aMirror Infohabitant MD, which migrates to the Environment 2 and makes aconnection to the Infohabitant E.

[0417] Whereas in the above embodiments, created software units, e.g.Mirror Infohabitants and CarrierPigeons, migrate upon creation, inalternative embodiments created software units do not migrate uponcreation but wait until receipt of a migration command specifying arespective destination set, e.g. the Environment 2 in the case of theMirror Infohabitant MA representing the Service Provider Infohabitant A,and, for a Mirror Infohabitant created by another Mirror Infohabitant, aunit of software of that respective destination set with which thatcreated unit is to establish a connection upon migration to thedestination set, e.g. the Infohabitant A in the case of the MirrorInfohabitant MB created by the Mirror Infohabitant MA.

[0418] It will be appreciated that in a system of the present invention,for convenience and simplicity all created units of software can havethe same, common software migration process, e.g. they migrate uponcreation, but depending upon the system design requirements, somecreated Infohabitants can migrate upon creation, e.g. MirrorInfohabitants, whereas other created Infohabitants, e.g. CarrierPigeons,can migrate upon receipt of a migration command. In variants, MirrorInfohabitants created by Infohabitants, e.g. the Mirror Infohabitant MA,migrate upon creation, whereas Mirror Infohabitants created by otherMirror Infohabitants, e.g. the Mirror Infohabitant MB, migrate uponreceipt of a migration command.

[0419] In a further alternative embodiment of the present invention, theMirror Infohabitants themselves do not comprise a software process whichis capable of migrating the Mirror Infohabitant from the Environment 1to the Environment 2, or the reverse direction, as the case may be.

[0420] Thus, in this further alternative embodiment, to make its serviceX available to Infohabitants in an Environment 2, the Infohabitant Acreates the mirror of itself, Mirror Infohabitant MA, by sending acreateInfohabitant request message to its InfohabitantGuardian proxy105, containing, inter alia, the type of the requested Infohabitant,RemoteCreationInfohabitant; the type of Infohabitant to be createdremotely, Mirror; the identity of the (remote) destination environmentwhere the Infohabitant is to be created, the Environment 2; parametersspecifying how to initialise the created (Mirror) Infohabitant. Theseparameters contain, inter alia, the address of the Infohabitant itrepresents (the identity of the Infohabitant, i.e. the name tag andfamily tag of the Infohabitant A, and the identity of the environmentwhere the Infohabitant A resides, i.e. the Environment 1), and a Familyflag, referred to herein as a specifier, specifying that the newlycreated mirror is to have the binary family tag of the Infohabitant A,as opposed to a non-specific, all-zero, family tag.

[0421] The Environment 1 now creates a RemoteCreationinfohabitant whichimmediately moves (migrates) to the Environment 2, creates the requestedMirror Infohabitant MA in the Environment 2, and then destroys itself.This constitutes indirect creation of the Mirror Infohabitant MA uponthe request by the Infohabitant A.

[0422] In other embodiments, instead of the Mirror Infohabitant MAdirectly creating the Mirror Infohabitant MB, which then migrates fromthe Environment 2 to the Environment 1, the Mirror Infohabitant MAindirectly creates the Mirror Infohabitant MB via a createInfohabitantrequest message, in a similar manner to the above described creation ofthe Mirror Infohabitant MA by the requested RemoteCreationInfohabitant.

[0423] In the above embodiments, the createInfohabitant request includesa type field for containing a type identifier for the type ofInfohabitant to be created, and, in addition, a number of parameterfields for containing one or more type-specific parameters whichdetermine how to initialise the Infohabitant upon its creation. In astill further alternative embodiment, in which the createInfohabitantrequest includes a type field, but has no parameter fields, createdInfohabitants receive details on how to initialise themselves, ordetails defining a specific task to be carried out, by sending them oneor more messages after they have been created. As will be readilyappreciated by one skilled in the art, this is only an implementationissue and any Infohabitant that has been described can easily beconverted to operate in such a still further alternative embodiment.

[0424] A Sorting Application Run on the Diet Platform

[0425] The DIET platform is geared towards a “bottom-up” softwaredesign. This is in the sense that a solution to a problem arises fromfunctionality implemented at the level of the individual Infohabitants,but emerges as a consequence of their collective interaction. (Thecontrast, “top-down”, would be a centralised process sendinginstructions to Infohabitants which they had to follow in implementingthe solution.) The sorting application is an example of this type ofbehaviour.

[0426] This application is built in layer three of the DIET architecture(recall that, from FIG. 18, this layer, the application layer 1810, iswhere application-specific code is located). It draws upon softwarecomponents in the ARC layer 1805 and in the core layer 1800.

[0427] To install and run an application such as the Sortingapplication, the following series of events takes place.

[0428] The SortingApp constructor first creates a World, then aThreadPool, then a series of Listeners to observe Events taking place inthe World, then passes the World and ThreadPool as parameters to anEnvironment constructor which creates an Environment. (Capitals are usedhere to refer to objects instantiated in Java.) This series of events atthe start of the call of the SortingApp constructor provides aninstantiated ThreadPool which will put limits on the processing capacitythe application will use.

[0429] Referring to FIG. 18, the application has been designed toarrange Linker Infohabitants 1700 in a sorted sequence. The only two“Infohabitant specific components” for the Linker Infohabitant arereferences to its two Connections. One Connection to a Linker with alower identity, and one Connection to a Linker with a higher identity.The Trigger has more “Infohabitant specific components”. Mostimportantly, a variable that controls how long it sleeps. It can alsohave additional parameters for instance that control how the sleepinterval should increase after an attempt to send a message has failed.

[0430] The Linker Infohabitants are sorted according to (the binaryvalues of) their identity. All Linkers are passive and only react toincoming messages. Each tries to maintain a connection to two otherLinkers: both as close as possible to its own identity but one with alower identity and one with a higher identity. When a Linker receives amessage with the identity of another Linker, it checks if it improveseither of its existing links. If it does, it updates the link and sendsits own identity to the corresponding Linker. Otherwise it forwards thereceived identity to the link with an identity closest to it. Thesorting process is driven by Trigger Infohabitants. They are active.Every once in a while they randomly select two Linkers and tell oneabout the other's identity. FIG. 17 shows a screenshot of avisualisation of this application. Individual Linker and TriggerInfohabitants are shown by blocks—lines between them indicate linksbeing formed between Infohabitants.

[0431] The application starts of because the Trigger Infohabitants areactive. Their behaviour is sufficient to start (and continue) thelinking behaviour.

[0432] To describe this process in more detail, the steps are asfollows.

[0433] There are two Triggers, although the number could be changed. ATrigger does not hold knowledge of the identities of all the Linkers atthe beginning but it can obtain knowledge of the identities of Linkers.The identities (name tags) have a numerical element and no twoidentities are the same. Each Trigger selects two Linkers at random andsends one of the selected Linkers the identity of the other selectedLinker.

[0434] Each Linker looks to see if it has recorded a link to a Linkerwith a closer identity already. If it has, it retains the recorded linkit already has and sends the identity received from the Trigger alongthis link to the Linker with a closer identity. This secondary Linkerrepeats the exercise, hence a cascade of messages can arise.

[0435] If a Linker finds that the numerical element of the identity sentby the Trigger, or received from another Linker, is closer to it thanthat of one of the links it has already recorded, it substitutes the newidentity as a recorded link and, other than notifying the newly linkedLinker of itself and notifying the old Linker of the newly linked Linkerbecause it is likely that both of these Linkers can improve their links,takes no further action, so the cascade dies out.

[0436] To start another cascade, the Triggers pick two more Linkers atrandom and start the process again.

[0437] At the beginning, cascades will die out quickly as the Linkershave no, or few, recorded links. As a chain of Linkers builds up, thereceived identities will get passed further “out” and thus the cascadewill take longer to die out.

[0438] A variation would be that the Triggers leave non-constantintervals between starting cascades as time goes by.

[0439] The Sorting application has a few interesting features. Firstly,although admittedly simple, this local and stochastic algorithm alwaysleads to a perfectly sorted list. Secondly, as sequences get longer, asingle trigger action typically results in a larger cascade of messages.Therefore, Triggers have a simple mechanism to adapt their activity tothe perceived system load. This simple adaptation strategy means thatthe system operates close to optimal efficiency despite changing systemload. Thirdly, the algorithm is robust. Even when messages get lost orLinker Infohabitants are killed, the algorithm keeps on functioning.Finally, the ability of the kernel to support light-weight Infohabitantsmeans that the application can run on a single computer with many, forinstance more than 100,000, Linker Infohabitants which means longsequences can be sorted.

[0440] Additional Aspects of the Diet Platform

[0441] Adaptability

[0442] There are various distinct ways an application can be adaptedwhile running on the DIET platform.

[0443] The Infohabitants can control the adaptation of the application.This can be done in various ways. Firstly, individual Infohabitants mayadapt their own behaviour. For instance, in the Sorting applicationdescribed above, the Trigger Infohabitants can decrease their activitywhen they perceive a high system load. When there are too many cascadesof messages occurring between Linkers at once, some message buffers ofLinker Infohabitants overflow. When a Trigger Infohabitant tries to senda message to an “overloaded” Linker Infohabitant, the message will berejected and the Trigger can conclude that the system load is too highand adjust its behaviour accordingly. Alternatively, an Infohabitant cancreate other Infohabitants when it thinks this is useful. For instance,when an Infohabitant has to reject requests because it cannot handlethem fast enough, it may create an Infohabitant similar to itself in anattempt to increase the capacity of queries that can be handled.

[0444] Clearly, creating new Infohabitants has the potential to increasememory use and use of processing capacity of the underlying system,which could be detrimental. However, there are two mechanisms forcontrolling this. Firstly, there is the limit on available threads inthe ThreadPool. Secondly, a resource accounting mechanism can be usedthat charges for all actions so that only successful Infohabitants canpay the cost required to create and maintain an additional Infohabitant.(This is further discussed below.)

[0445] The Environment can control adaptation of the application. Again,a resource accounting implementation (briefly mentioned above andfurther discussed below) is a natural way to achieve this.

[0446] The User can control the Infohabitants. One way is to provide atool, preferably graphical, that allows the user to create, destroy andinteract with Infohabitants.

[0447] Resource Accounting

[0448] The InfohabitantGuardian monitors resources belonging to anInfohabitant. All kernel services provided by the Environment (e.g.setting up a new connection) are passed through the InfohabitantGuardian(see FIG. 1). So for every kernel service that it forwards to theEnvironment it can subtract resources from the Infohabitant's account.When its resources are not sufficient it can destroy the Infohabitant.In one way of implementing resource accounting, the Infohabitantsreceive resources when they are created and during their lifetime as areward for specified actions (from the User, the Environment or fromother Infohabitants). In this way unsuccessful Infohabitants aredestroyed, whereas successful ones are maintained and possibly createoffspring. As a result an evolutionary process can take place within theDIET platform which can help the application to adapt to changingcircumstances.

[0449] Infohabitant Destruction

[0450] Infohabitants cannot normally directly kill other Infohabitantsin the DIET platform. The reason is that each Infohabitant has onlyaccess to a limited set of objects with limited capabilities. TheInfohabitantGuardian and ConnectionEnd proxies shield Infohabitants fromdirect access to their environment and other Infohabitants. However,when a DIET system is started, it is possible to provide any selectedobject (e.g. a debugging and visualisation tool) with direct access tothe World, and the “ListenerCookie” required for listening to eventsthat take place once the system is running. Any object that has accessto the DIET World can then closely examine what happens as well asactually control what happens (i.e. destroy Infohabitants). However, theDIET platform allows the user to control which objects have access tothe World, and as long as the user does not explicitly give such accessto Infohabitants at installation, the system is secure from Infohabitantdestruction for instance via applications in the Application layer 1810.

[0451] Unless the context clearly requires otherwise, throughout thedescription and the claims, the words “comprise”, “comprising” and thelike are to be construed in an inclusive as opposed to an exclusive orexhaustive sense; that is to say, in the sense of “including, but notlimited to”.

[0452] Any discussion of the prior art throughout the specificationshould in no way be considered as an admission that such prior art iswidely known or forms part of common general knowledge in the field.

1. A system for distributed process management comprising a plurality ofunits of software for installation on a computing platform, and furthersoftware for controlling the operation of the plurality of units in useof the system, wherein: each unit of software is provided with means forcommunicating with other units of software by the sending and receivingof messages; at least some of the units of software are further providedwith means for providing one or more elements of a software process; andsaid further software is capable of defining a plurality ofenvironments, each of said environments containing a respective set ofsaid units of software and being resident on a single computer of thecomputing platform, and wherein, for each said environment, a unit ofsoftware of its respective set can request a connection to an identifiedunit of software, and that request will be rejected if that identifiedunit of software is not a current member of that respective set.
 2. Asystem according to claim 1, wherein each of said plurality of units ofsoftware is provided with an event portal having a buffer for storingevents incoming to that unit of software from initiating ones of saidunits of software, wherein the buffer has a predetermined capacity forstoring events and incoming events exceeding that capacity result in thegeneration of respective rejection notifications for the correspondinginitiating units of software.
 3. A system according to claim 2, whereinthe event portal is provided with a plurality of buffers and events arestored for processing in a selected buffer, each said buffer having apredetermined capacity.
 4. A system according to any one of thepreceding claims, wherein at least one unit of software is provided withcode to provide a software process for establishing a connection betweenfirst and second other units of software, said process includingtranslation of the identity of at least the first of said other units ofsoftware, such that the identity is hidden from the second of said otherunits of software while the connection is established.
 5. A systemaccording to claim 1, wherein the further software defines more than onesaid set, and wherein communication between a first said unit ofsoftware, referred to hereafter as the first unit, in a first said setand a second said unit of software, referred to hereafter as the secondunit, in a second said set is by means of messages sent from the firstunit to a said unit of software in the first set and representing thesecond unit, referred to hereafter as the second unit representative,relayed from the second unit representative to a said unit of softwarein the second set and representing the first unit, referred to hereafteras the first unit representative, and forwarded from the first unitrepresentative to the second unit, and mutatis mutandis for messagessent from the second unit to the first unit.
 6. A system according toclaim 5, wherein the first unit is capable of (a) requesting the furthersoftware to establish the first unit representative in the second set bycreating the first unit representative initially in the first set, thefirst unit representative so created comprising a software process whichis capable of migrating that unit from said first set to a specifiedsaid set, and (b) specifying that the first unit representative socreated is to migrate to the second set.
 7. A system according to claim5, wherein the first unit is capable of (a) requesting the furthersoftware to establish the first unit representative in the second set bycreating a said unit of software in the first set, the unit of softwareso created comprising a said migrating process which is capable ofmigrating that unit to a specified said set, and (b) specifying that theunit of software so created is to migrate to the second set and, whenresident in the second set, is to create the first unit representative.8. A system according to either claim 6 or claim 7, wherein the firstunit representative is capable of (a) requesting the further software toestablish the second unit representative in the first set by creatingthe second unit representative initially in the second set, the secondunit representative so created comprising a software process which iscapable of migrating that unit from said second set to a specified saidset, and (b) specifying that the second unit representative so createdis to migrate to the first set, and wherein the second unitrepresentative is capable, when resident in the first set, ofestablishing a connection to the first unit.
 9. A system according toeither claim 6 or claim 7, wherein the first unit representative iscapable of (a) requesting the further software to establish the secondunit representative in the first set by creating a said unit of softwarein the second set, the unit of software so created comprising a softwareprocess which is capable of migrating that unit to a specified said set,and (b) specifying that the unit of software so created is to migrate tothe first set, and, when resident in the first set, is to create thesecond unit representative, and wherein the second unit representativeis capable of establishing a connection to the first unit.
 10. A systemaccording to claim 5, wherein the first unit is capable of (a)requesting the further software to establish the first unitrepresentative in the second set by creating a said unit of software inthe first set and (b) specifying that the unit of software so created isto be the second unit representative, and that the second unitrepresentative so created is to be capable of requesting the furthersoftware to establish the first unit representative in the second set.11. A system according to claim 10, wherein the second unitrepresentative so created is capable of requesting the further softwareto establish the first unit representative in the second set by creatingthe first unit representative initially in the first set, and whereinthe first unit representative so created comprises a software processwhich is capable of migrating that unit from said first set to aspecified said set, and wherein the first unit specifies that the firstunit representative so created is to migrate to the second set, andwherein the first unit representative is capable, when resident in thesecond set, of establishing a connection to the second unit.
 12. Asystem according to claim 10, wherein the second unit representative socreated is capable of (a) requesting the further software to establishthe first unit representative in the second set by creating a said unitof software in the first set, the unit of software so created comprisinga software process which is capable of migrating that unit to aspecified said set, and (b) specifying that the unit of software socreated is to migrate to the second set and, when resident in the secondset, is to create the first unit representative, and wherein the firstunit representative is capable of establishing a connection to thesecond unit.
 13. A system according to any one of claims 6 to 12,wherein in each said set the units of software have unique localidentities.
 14. A system according to claim 13, wherein the localidentity of said first unit includes a specific family identifieridentifying a function to be provided by said first unit for other unitsof software of said first set; and said further software is capable ofcreating said first unit representative such as to have either saidspecific family identifier or a non-specific family identifier inaccordance with a specifier in said request by said first unit independence upon whether or not said function is to be made available tounits of software of said second set.
 15. A system according to eitherclaim 13 or claim 14, when claim 13 is dependent upon either claim 8 orclaim 9, wherein the local identity of said second unit includes aspecific family identifier identifying a function to be provided by saidsecond unit for other units of software of said second set; and saidfurther software is capable of creating said second unit representativesuch as to have either said specific family identifier or a non-specificfamily identifier in accordance with a specifier in said request by saidfirst unit representative in dependence upon whether or not saidfunction is to be made available to units of software of said first set.16. A system according to either claim 13 or claim 14, when claim 13 isdependent upon any one of claims 10 to 12, wherein the local identity ofsaid second unit includes a specific family identifier identifying afunction to be provided by said second unit for other units of softwareof said second set; and said further software is capable of creatingsaid second unit representative such as to have either said specificfamily identifier or a non-specific family identifier in accordance witha specifier in said request by said first unit in dependence uponwhether or not said function is to be made available to units ofsoftware of said first set.
 17. A system according to any one of claims6 to 16, wherein each of said unit representatives is capable of (a)requesting the further software to create a unit of software, referredto hereafter as a carrier unit, the said carrier unit so created beingcapable of carrying a said message and comprising a software processwhich is capable of migrating that unit to a specified said set, and (b)specifying that the carrier unit so created is to migrate to the set ofthe other of said unit representatives, connect to the other of saidunit representatives and deliver the carried message.
 18. A systemaccording to claim 17, wherein a said carrier unit is capable of reusefor carrying a message in the reverse direction.
 19. A system accordingto either claim 17 or claim 18, when both of claims 13 and 17 aredependent upon any one of claims 8 to 12, wherein a said unitrepresentative, so created and capable of requesting the furthersoftware to establish the other of said unit representatives, is furthercapable of (a) requesting the further software to create directly orindirectly said other of said unit representatives to be capable ofrequesting the further software to create the said carrier unit to havean identifier specific to the said unit representative, and of (b)requesting the further software to create a said carrier unit to havesaid specific identifier, and wherein each of said unit representativesis capable of determining the future handling of a message received viaa carrier unit in dependence upon whether or not that carrier unit hassaid specific identifier.
 20. A system according to any one of claims 6to 9 and 11 to 19, wherein the software process which is capable ofmigrating its unit to a specified set is arranged to migrate thatcreated unit upon its creation.
 21. A system according to any one ofclaims 6 to 9 and 11 to 19, wherein the software process which iscapable of migrating its unit to a specified set is arranged to migratethat created unit upon receipt of a migration command.
 22. A systemaccording to any one of claims 6 to 21, wherein communication betweenunits of software is indirect, being established by means of connectionproxies, and wherein, for each respective connection that a said unit ofsoftware establishes with other said units of software, a respectivepair of connection proxies is generated.
 23. A system according to claim22, wherein at least one connection proxy of at least one of saidrespective pairs has a reference to a transaction state.
 24. A systemaccording to either claim 22 or claim 23, wherein at least one unit ofsoftware is provided with a respective proxy having means to monitor andcontrol any connection that the unit of software establishes via saidconnection proxies.
 25. An applications platform for installation in acomputing environment to support the running of an application by use ofprocessing and data storage capacity of the computing environment, theplatform comprising means to create a community of software units andmeans to provide a support software environment to the community,wherein an application to be run on the platform is installed asprocesses of a selected plurality of the community of software units,and processes for support of the application in use are themselvesinstalled on further software units of the community.
 26. A platformaccording to claim 25, wherein the means to provide a support softwareenvironment to the community maintains a plurality of units ofprocessing capacity of the computing environment for allocation toselected units of the community of software units during running of anapplication.
 27. A platform according to claim 26, wherein the number ofunits of processing capacity is less than the number of software unitsin the community.
 28. A platform according to either claim 26 or claim27, wherein said plurality has a maximum number which is determined whenan application is first started.
 29. A platform according to any one ofclaims 26 to 28, wherein each software unit in the community is providedwith an identity.
 30. A platform according to claim 29, whereincommunication between the software units in the community is enabledusing their identities.
 31. A platform according to any one of claims 25to 30, wherein each software unit is arranged such that, regardless ofwhether or not it is currently allocated a unit of processing capacityof the computing environment, communication therewith can be initiatedby another software unit.
 32. A platform according to claim 31, whereineach software unit is provided with means to maintain state informationin relation to a communication with another software unit and eachsoftware unit maintains that state information whether or not it iscurrently allocated a unit of processing capacity of the computingenvironment.
 33. A platform according to claim 32, wherein each softwareunit is provided with at least one dedicated software unit forperforming a dedicated function.
 34. A platform according to claim 33,wherein at least one dedicated software unit is arranged for receptionand transmission of messages for its software unit.
 35. A platformaccording to either claim 33 or claim 34, wherein said at least onededicated software unit maintains at least one element of data relevantto its associated software unit.
 36. A platform according to claim 35,wherein one element of data maintained by a dedicated software unit isthe state information in relation to a communication with anothersoftware unit.
 37. A platform according to either claim 35 or claim 36,wherein one element of data maintained by a dedicated software unit isthe identity.
 38. A platform according to any one of claims 33 to 37,wherein one element of data maintained by a dedicated software unitprovides a measure of success of the software unit to which it isdedicated, said measure of success being a factor in replication ordestruction of the software unit such that the community is capable ofadaptation.
 39. A platform according to any one of claims 22 to 38,wherein each software unit in a community is provided with a portalprovided with means to store event data in relation to events yet to beprocessed by the software unit.
 40. A platform according to claim 39,wherein said event data includes a count of events yet to be processed.41. A platform according to claim 40, wherein the portal maintains amaximum in relation to the count of events yet to be processed, anyincoming event being rejected once the count has reached its maximum.42. A platform according to claim 41, wherein the portal maintainsmultiple counts of events in different type categories, and a maximumfor each of said multiple counts.
 43. A platform according to any one ofclaims 32 to 42, when claim 39 is dependent upon any one of claims 23 to38, wherein if an event requires that a software unit be allocated aunit of processing capacity and that software unit is not currentlyallocated a unit of processing capacity, the computing environment willautomatically allocate that software unit an available unit ofprocessing capacity.
 44. A platform according to any one of claims 32 to42, when claim 39 is dependent upon any one of claims 23 to 38, whereinif an event requires that a software unit be allocated a unit ofprocessing capacity, that software unit is not currently allocated aunit of processing capacity, and the computing environment does not havea unit of processing capacity available for allocation, that event isrejected by the software unit.
 45. A platform according to any one ofclaims 22 to 44, wherein the support software environment is adapted tosupport: creation of software units to add to a community, migration ofsoftware units out of the community to a community supported by adifferent software environment, and communications connections betweensoftware units of the community.
 46. A platform according to claim 45,wherein the support software environment is further adapted to supportdestruction of software units of the community.